Custom MP3 Player

[Zresh]

As the title says I'm considering having a custom MP3 Player built and was wondering if it was possible if Rockbox would work on it as the main OS without the need for side loading and if so what spec's the player should have. If a new player can be built and would work I'd have the plan's made open source so anyone could build there own player if desired.

Here's some details of the player I put together real quick in the attachments.

As this isn't something I'm well versed in I don't know if a GPU is needed or not and the rest is what I thought would make for a good long term player. The ?'s aside from the CPU/GPU are for feature's I'm not sure I'd want but if this is something that might work and can be built would be added if other people wanted.

Any thought's on if this would work, why it wouldn't, if it was built if a new OS would be needed or if Rockbox could be made to work would be greatly appreciated.

[speachy]

I wrote this up several years ago.  Updated it a little this morning.

  https://www.shaftnet.org/~pizza/rb-wishlist.txt

Based solely on your specs, I'd eschew large amount of on-device storage for a simple SD card slot.   It also has the advantage of being easily replaceable so you don't have to worry about the on-board flash wearing out.

I'd also strongly caution you about multi-touch screens -- touch is nice to have, but it makes the device unusable if you're not looking at the screen.  Physical buttons are strongly preferred.

The sad truth of the matter is that most modern DAPs, especially the ones built on Android or other touch-first environments, lean in hard to gimmicks and give very little thought to UI/UX.  If you want a smartphone-like UI playing back via bluetooth, then.. why not use the smartphone you already have?

[gevaerts]

8GB of RAM is *vastly* more than an mp3 player needs. For Rockbox, something like 8MB might be enough, although a bit more (32MB or 64MB) might be better. Some of this also depends on screen resolution.

I'd recommend having a look at the specifications of some existing players to get a better idea.

[Zresh]

Alright here are a few changes to the spec's list and a very rough picture of what I'm planning for the body. Not sure where the micro-sd slot will go yet. The two red spots on the back are where speakers might go if there included, if anyone has a different idea for there placement let me know.

On that note still looking for opinion's on if speakers and Wi-Fi should be included and if it needs a cpu/gpu or something else.

[speachy]

...So you're gravitating towards a 6th-gen iPod form factor.

You need to decide if you're going to use something like Android, Rockbox, or something entirely different (do _NOT_ underestimate the level of effort of writing something from scratch!) because that will drive the rest of the fundamental system requirements (ie CPU oomph, GPU, RAM and onboard flash requirements)

If you're intending to run Rockbox on this thing, I recommend using a SoC that has embedded DRAM; something like the Allwinner V3s or Ingenic X1000/X2000.  Alternatively, use an SoC that can stack the DRAM on top (eg the BCM4325? on the RPi series)  Not needing off-chip DRAM will _drastically_ simplify your PCB. 

IMO, Speakers in-device is, like many other things, a mostly useless gimmick, and if they're not complete crap will take away case space from something that matters more, like the battery.

As for WiFi, what's the use case?  Data transfer (via what mechanism/protocol? Consider you'll need server and/or client software to make this happen!) or commercial streaming audio services?  If it's the latter then you'll need a huge bump in specs so the device is capable of running Android reasonably well as these services don't make a habit of allowing 3rd-party clients.

I also don't recommend using a hard power switch; power off needs to be under OS control so we can ensure filesystems are in a safe state and all data has been fully flushed.  Use it as a lock switch instead.   I'd also recommend dedicated volume buttons.

That document I linked above has a lot of details and justifications.

[vitt13]

here are a few changes to the spec's list and a very rough picture of what I'm planning for the body

It almost reminds me Innioasis Y1 player  https://fccid.io/2A6DB-Y1/Internal-Photos/Internal-Photos-6262700
But it's with lower battery capacity, smaller form size than you request and BTW without dedicated hi-res DAC.

[amachronic]

For what it's worth I've been working on an STM32H7-based design using external SDRAM, also targeting an iPod 6g-like form factor. These are the specs:

• STM32H743 @ 480 MHz
• 32 MB of SDRAM
• SD card bus up to 25 MB/sec
• USB Type-C connector muxed between USB 2.0 HS PHY (for main USB functionality) and STM32's builtin USB 1.1 PHY (so it can be flashed without SWD)
• 3.5mm headphone jack driven by PCM5102A DAC + LM4810 amplifier
• Support for headset inline remote buttons compliant to the Android 3.5mm accessory specification
• Headset mic support -- not going out of my way for this, so there is a chance it will not work very well or at all. It's just there as a consequence of supporting headset buttons so why not.

I've almost finished with the high-speed bus routing: SDRAM is done, USB is mostly done. The SD bus isn't routed but should be very easy to do. Still need to place the LCD, buttons, power supply, crystals, and audio components. I'm planning on a 320x240 LCD over SPI, which is maybe not ideal, but the only other option is a parallel RGB bus and I'd rather not route another big parallel bus since things are already pretty crowded near the MCU. I'm trying to stick to a 4-layer PCB because moving to 6+ layers bumps up the cost for prototypes significantly.

Compared to speachy's wishlist I am missing a few things (UHS-I, OTG, separate line-out port, 60 FPS display) but they aren't showstoppers and could probably be added in a future revision. Only UHS-I is really a pain, because then you need a level shifter + 1.8v supply on the board, and most of my parts require 3.3v.

Right now I am trying to do the case design since I now need to place & route the external connectors. I'm thinking of a Sansa-esque d-pad with 2-4 extra buttons on the faceplate, volume buttons on the side, and a power/hold switch on the top edge; another option is a power button on the top/sides. USB and SD connectors on the bottom edge and 3.5mm jack on the top.

One of my constraints is only using components which are plentiful on LCSC, mostly for cost and convenience, and hopefully the parts will still be available in a few years time. A better option for the MCU would be the STM32H7S3, which has an embedded USB 2.0 PHY, and the PSSI interface which I think could be used for connecting 8-bit parallel 8080 LCDs in conjunction with a separate clock output, but it's not available from LCSC. Proper PMICs are hard to find, as are high quality audio codecs, hence why I've gone for the discrete DAC + amp combo. But barring any stupid mistakes on my part I think the quality should be fine.

I do plan on releasing the PCB and case designs as open-source once I get closer to finalizing them.

[7o9]

I do plan on releasing the PCB and case designs as open-source once I get closer to finalizing them.

Sounds very interesting!

Do you plan do some sort of batch of assembled devices too? I would be happy to support that.

[lubatur]

I would also like to support this.

[speachy]

For what it's worth I've been working on an STM32H7-based design using external SDRAM, also targeting an iPod 6g-like form factor. These are the specs:

• STM32H743 @ 480 MHz

Sweeeeeet.   FWIW I am particularly fond of the STM32 family, and that has only grown the more I've had to deal with the competition....

I'm planning on a 320x240 LCD over SPI, which is maybe not ideal

Given the STM32's DMA engine(s), we could probably just have it on a continual (double-buffered) refresh cycle.  At 320x240x16bpp, 25MHz 1-bit SPI would net us about 20fps.  If we can get 2 or 4-bit SPI that ought to scale nearly linearly.
 

Compared to speachy's wishlist I am missing a few things (UHS-I, OTG, separate line-out port, 60 FPS display) but they aren't showstoppers and could probably be added in a future revision. Only UHS-I is really a pain, because then you need a level shifter + 1.8v supply on the board, and most of my parts require 3.3v.

Yeah, no 1.8v supply does hurt. What do you intend to do for power/battery management?  (And not having UHS-1 won't really be visible except when doing file transfers...)

I look forward to seeing what you come up with!

[amachronic]

I do plan on releasing the PCB and case designs as open-source once I get closer to finalizing them.

Sounds very interesting!

Do you plan do some sort of batch of assembled devices too? I would be happy to support that.

Yeah, if there is enough interest then I don't see why not, but I haven't put much thought into how best to do it so I'm open to suggestions. For a low enough volume I'm happy to order a bunch of PCBs pre-assembled, put them in cases and ship them myself, but for any significant number of units that isn't practical.

For what it's worth I've been working on an STM32H7-based design using external SDRAM, also targeting an iPod 6g-like form factor. These are the specs:

• STM32H743 @ 480 MHz

Sweeeeeet.   FWIW I am particularly fond of the STM32 family, and that has only grown the more I've had to deal with the competition....

I'm planning on a 320x240 LCD over SPI, which is maybe not ideal

Given the STM32's DMA engine(s), we could probably just have it on a continual (double-buffered) refresh cycle.  At 320x240x16bpp, 25MHz 1-bit SPI would net us about 20fps.  If we can get 2 or 4-bit SPI that ought to scale nearly linearly.
 

Compared to speachy's wishlist I am missing a few things (UHS-I, OTG, separate line-out port, 60 FPS display) but they aren't showstoppers and could probably be added in a future revision. Only UHS-I is really a pain, because then you need a level shifter + 1.8v supply on the board, and most of my parts require 3.3v.

Yeah, no 1.8v supply does hurt. What do you intend to do for power/battery management?  (And not having UHS-1 won't really be visible except when doing file transfers...)

I look forward to seeing what you come up with!

I think the power circuit will (vaguely) be a battery charging IC + separate buck converters for the digital/analog domains + an LDO to keep the RTC ticking while otherwise powered down. And I'll likely want some FETs for switching things on and off, like the audio circuit. I haven't decided yet if I want to try doing CPU core voltage scaling in this revision but I was intending to. For actually powering on and off I'll have to use some wired-OR type of arrangement -- the power button and a GPIO will both hold power open, but it can only shut down under software control. In case the CPU hangs I can link that GPIO to a timer/PWM output so it will power down unless the timer periodically reset. Without a PMIC or a helper chip I don't think there is a way to have the power button do anything special when held down for a long time (except maybe some analog trickery -- like slowly charging a capacitor).

The battery will either be a generic LiPo cell, probably with a JST connector for easier replacement, or the Nokia BL-5C, which are both relatively easily available. Cylindrical cells would end up making the case really bulky or require cutouts on the PCB (and still make the case fairly bulky) so they're not really a practical choice, unfortunately.

[vapre]

I am interested. Are there any plans for bluetooth audio?

[redblade8]

This would be cool indeed. Things I look for are microphone recording, and FM radio recording, possibly AM radio.
Another good one would be an external speaker.

Thanks for reading
- Red.