Project Logs

Collapse

• Album Artwork Cache

  Eric Min • 06/20/2026 at 05:04 • 0 comments

  Right now, displaying album art on StereoBoy is a painfully slow process. The RP2350 extracts album covers from MP3 metadata, which is slow and takes up to 10+ seconds for hi-res artwork. Obviously, this is not ideal. I knew the artwork system had to change, but I didn't really know how.

  But then, I remembered the original iPod's user interface, which had full support for album covers, allowing cool features like Cover Flow that let users glide through album covers quickly with minimal latency. I decided to look into how the iPod achieved this, since their CPU was a simple ARM chip, actually much less powerful than the RP2350.

  I learned the iPod actually used a cache for its artwork, instead of extracting it from the song metadata. When syncing, iTunes would also extract and downsample the album covers and store it in the iPod's hard drive. That way, the iPod could just look up the cached artwork instead of having to pull it from the file every time. I figured it was simple enough for me to give a go for StereoBoy.

  After some thinking, I arrived on this:
  

  The cache system will consist of two files: A LUT and the artwork cache. The LUT will be a dictionary, consisting of pairs of a hash and a corresponding pointer. The hashes will be generated by a very simple FNV-1a algorithm from the track's title, artist, and album data, and the pointers will be the address within the artwork cache that contains the artwork for the given song. The artwork cache will be a single monolithic file containing a 160x160 RGB565 array for each album cover. A simple program, like a python script, will be run on the host computer's side to generate the LUT and cache. This will be the equivalent of iTunes for the iPod.

  On StereoBoy's side, the LUT and cache will be stored on the SD card. Whenever the album cover needs to be displayed, the RP2350 will generate its own hash from the currently selected track, and use that hash to look through the LUT to find the corresponding pointer. Then, it will look through the cache file, and use the pointer to find the album cover to fetch and display on the screen. Looking through the LUT will be a simple binary search with a big-O of O(log(n)), and fetching the artwork will be O(1). I think this will be quite fast, especially considering the faster processor and disk speed of StereoBoy compared to the original iPod. Remember, the Classic line used spinning hard drives!

  Assuming a library of 5000 songs, the resulting LUT will be about 60KB, and the artwork cache will be about 256MB. I think the LUT should easily fit in the RP2350's main memory, so I'll try to load it into ram on bootup. This should make the hash lookup super fast. As for the artwork cache, it might take a fraction of a second, maybe a bit noticeable, but I don't think it will be a big deal.

  Edit: I got it working the next day, it works almost flawlessly. I say almost because the RP2350 takes a fraction of a second to fetch the image from the SD card, and it's pretty noticeable, especially if it happens in the middle of playback. It's caused because the fetch process halts Core 0, which is responsible for audio playback. But if I put the fetch process onto Core 1, there is contention for the SD card from both cores, so I need to find a way to run the process on Core 0 while still keeping audio playback happening in the background. Perhaps it's time for me to move the audio streaming process from CPU to DMA. After all, it's been on my list for a while and long overdue.
  
  
  

• StereoBoy R2 - PSU redesign for LiPo

  Eric Min • 05/25/2026 at 20:48 • 0 comments

  I'm insanely happy with the results of our first prototype, StereoBoy R1.

  Pretty much all hardware functionality is confirmed working, from small things like the thumbwheel potentiometer to XIP from QSPI flash wired over a GameBoy cartridge connector, which I was pretty scared on whether it would work or not. Well, it works beautifully.

  The past few days, I've shoehorned a LiPo charger module into the device and fit a 500mAh lipo cell into the battery well. With simple testing, I got over 4 hours of continuous playback from headphones. This isn't the best, but I still think this is better than AAAs, which had a battery life of 5 hours for non-rechargeable alkalines and 2.5 hours for rechargeable NiMH cells. So I'm planning on redesigning StereoBoy R2's PSU to use LiPo batteries instead of AAAs.
  
  

  This means future StereoBoy models will only be able to use aftermarket shells with modified battery compartments, not the original shell. But aftermarket shells are available easily for cheap online, so I don't think this will be a huge deal.
  
  

View all 2 project logs