Music32-V2 - Portable music player

Recreating the ipod with Bluetooth and an SD card slot, without losing the headphone jack

Similar projects worth following
This is an attempt to make an ipod-like device which will be able to play most major digital music formats from a SD card and play it back through headphones, wired or wireless. It features a clickwheel with 6 touch sensing sections and tactile buttons underneath for button presses because who doesn't like tactile buttons?

Hoped to get drag and drop functionality going over USB with the esp32s3 but just couldn't figure it out, maybe someone smarter will have a go in future. Doesn't matter, I'm not planning on using the s3 in the next version anyway and wireless file transfer is in the works. If that doesn't work out then might have to built a SD card reader into the board but I don't like that solution. Not like anything would stop you from just popping out the SD card though.

Dimensions of the device are 55mm (W) * 105mm (L) * 16mm (H), could be made much thinner if you want to reduce the battery capacity.

Feel free to ask questions or message


  • Stereo analog audio out (3.5mm)
  • ES8327 CODEC 24-bit, 96khz max 
  • Internal microphone
  • Headphone present detect, can pause music when headphones removed
  • Replaceable 2500mah lipo battery, capacity can be changed by user
  • Charge and power indicator lights
  • Data and power over USB-C
  • FR4 front and back plate, stylish and structural
  • Hold/Power slide switch
  • 2" Colour IPS LCD, 240*320 pixels
  • ESP32-S3 with 16MB flash 8MB PSRAM
  • Real time clock with configurable interrupt
  • Clickwheel with 5 tactile buttons and 6 capacitive sensing electrodes
  • Micro SD card slot (push-push spring loaded)
  • Fuel gauge with configurable interrupt
  • USB MSC drag and drop onto SD card (WIP)
  • Easy to repair construction, 4 hex bolts 
  • Fully open source

What is not on the V2

  • Bluetooth classic - theres going to be a mcu change for V3 to allow this
  • Haptic feedback for clickwheel

Analog audio is managed by a ES8327 CODEC chip. The audio is sent out over a standard 3.5mm headphone jack in stereo. I have so far tested with 16 ohm and 60 ohm headphones. The 16 ohms can have a slight static in the backround but this goes away completely on the 60 ohm headphones. Hoping to get that sorted out though since I use 16 ohm earphones usually. Apart from playback it also supports recording, with both an internal mic and the ability to use the headphone mic of wired headphones. By using a codec not only do you gain recording but also we should be able to detect buttons on headphones. 

Power comes from a 2500mah battery, connected through a 2mm JST connector. The battery is recharged when plugged into the USB-C port, with charge indicator lights near the port. 

The display is a 2" IPS LCD, backlit of course with full colour at a resolution of 240*320 pixels. Being used with the tft-espi library at 80MHz.

Main processor is a ESP32-S3 WROOM module. Chose a wroom module because its so much easier to design for and assemble. Especially since its all pre certified wireless so no worries there. Also using one of the chips directly does not provide any space, assembly or cost benefits. Code is uploaded over the internal usb peripheral. To upload code you just press and hold the top button on the clickwheel (io0) and press the reset button through the small hole in the lower right corner of the top plate. That puts the ESP32 into download mode and you can upload over the com port that will show up on the computer. 

There is PCF85063 real time clock onboard which should allow the device to keep time accurately, I could have used the "internal RTC" of the ESP32 but I needed every GPIO pin.

The clickwheel is connected by a ribbon cable to the main board, with a connector on the main board for easy replacement. Same goes for the battery with its JST connector, should be very easily replaceable or interchangeable with other battery capacities. Just need to change the value of the resistor as per the LGS4056 datasheet to set the correct charge current for the battery you choose to use, i've marked this resistor with a star on the silkscreen. Though it is 0402 like every other resistor on the board, I definitely could have made it easier in that regard but if you are going to be making this board id think you can solder and desolder 0402 components. If this turns out to be a problem i'll make the changes for a next revision.

I want to talk a bit more about the clickwheel, because its something that needs to be changed for the next version.

Clickwheel electrode layout

Now to start off, it works really well. Im quite happy with its performance and i'm blow away by the interpolation. Check out the logs if you want to see that demo. Currently i'm using it as a software defined 12 segment wheel and loving its performance. But to get to what I don't like, it's gotta be the assembly of the wheel. The ribbon cable is soldered directly onto the clickwheel which is a fairly difficult job, not impossible though and i've got two functional wheels. Just really tedious to solder as its 8 little metal strips...

Read more »

  • Progress

    Nic02/24/2024 at 10:46 0 comments

    Hi everyone, just another quick update to show this project isn't dead yet. Ive now properly implemented the link functionality, allowing the sd card to seamlessly connect to a computer. Using a V30 sd card I was able to get 30MB/s easily, definitely fast enough for what I need at least. I also put together a simple case to make development easier but it needs a bit of refinement.

    You can see the slot for the master battery power switch, the sd card slot and volume rocker

    This is the clickwheel design, its got two little hooks to clip on to the encoder and a gimbal mechanism that allows all the buttons to be pressed without stress on the encoder. The axles are just the legs of 1/4W resistors. It does work but the tolerance is a bit too loose so its a bit clumsy. Ive been testing a couple different resins to find one that has the right properties for the job and each has different tolerances.  This means clickwheel is resin printed, I did try a lot with many designs trying to make fdm work but the scale is just impossible.

    Currently I am occupied with life but the next things on the list are:

    • Comprehensive file explorer and playlist configurations stored on sd card
    • Handling switching between audio decoders, audio playback logic
    • Clickwheel tolerances and resin selection

    Currently verified as working:

    • Display 
    • Esp32
    • Usb hub
    • Sd card reader
    • Codec audio out and microphone
    • Sd card data and power switches
    • All buttons and switches can be read
    • Programming circuitry
    • Encoder
    • SD card detection


    • Battery power operation
    • Battery undervoltage cutoff
    • Battery isolation switch
    • Fuel guage (the library is unreliable)

  • PCBS are here

    Nic12/19/2023 at 15:17 0 comments

    PCBs have just arrived from PCBway, huge thanks to them for supporting this project by supplying the PCB's. They have come out looking great, everything is very sharp and the finish is wonderful. Their customer service was very helpful and responsive which was great.

    The boards got solderpaste applied with a stencil also from PCBway, then loaded up with components and cooked on a hotplate. First things I noticed while assembling was that the side buttons werent exactly the right ones, but I just bent the support pins to make them full smd. Another thing was that when doing the side with the buttons and encoder its best to do the buttons then place the encoder on and solder it as the hot air has a hard time getting into the middle of the encoder.  

    The board worked as soon as I plugged it in (though I needed to remove a stray 0.2 ohm resistor), I could see the CH340 and SD card reader pop up. Which means the hub was working perfectly. So far ive tested the codec, which performs even better then the last version, the display, buttons, encoder and SD card reader. For the reader I wrote a short program to switch the analog switches to connect the reader and sd card and power on the sd card. Immediately a flash device appeared on my computer and I could drag and drop easily. Im only using a speed class 10 micro sd so I got 12MB/s write and 30MB/s read but I suspect it can go much higher with the correct sd cards, the chip itself can handle up to 2TB micro sd cards. Evenly this comparatively slow speed was enough to transfer 170 .m4a songs over in about a minute which I was quite happy with. Of course the sd card also works fine with the ESP32, I even got exfat working so big capacity cards can now be supported. 

    Other then that I don't really have much else to report, everything works and its been a great success, I couldn't have hoped for a better outcome so far. Now im just back to writing software which is going to take forever for me. If someone has 10s of hours of free time on their hands give me a ring because the 1s and 0s scare me. Thanks again to PCBway for supplying pcbs for this project, I do really appreciate it. 

    If your wondering that thing below the screen left is a bodge solder reconnection of a trace because I cut it to find that pesky 0.2 ohm resistor that snuck in to my 10KS

  • V3 PCB is designed

    Nic12/03/2023 at 03:40 0 comments

    Just an update that the V3 is happening, here are some pics of the pcb

  • Input mechanism for the V3

    Nic11/01/2023 at 11:46 5 comments

    Ive been thinking about potential input devices for the V3 design. 

    Previously the plan was to use an external capacitive sensing chip, because the ESP32 doesnt have enough gpio to handle everything and touch sensing is the most sensible to allocate to another chip. This would then run an improved clickwheel design in a similar manner to the current system. 

    However, I recently decided I wasn't really a fan of the capacitive clickwheel. Don't get me wrong it works quite well. It just takes a lot of processing code and now id need to handle fetching data from an external sensor as well. It also takes power to run the chip and its haptic feedback and still doesn't feel as nice as the real thing. 

    So I started looking for other input methods and to cut to the chase Ive looked at magnetic, horizontal mechanical, vertical mechanical and optical. None of these really ended up being a good fit for the job, with all of them having at least one big flaw with how they had to be used in this situation. This situation doesnt just mean a clickwheel or similar either, just a rotary input method that was convenient and comfortable to use.

    There is one exception though, which was a wonderful and very small smd hollow shaft mechanical encoder. It is also only about 2cm wide and 2mm tall, which is extremely manageable and easy to work around. So I was thinking, why not just recreate the original ipod wheel, but better and easier to use? The encoders hollow shaft can easily accomodate a button and theres no other spacing issues, even the vertical height of the player wont be impacted at all. 

    So now my plan is to make the original ipod clickwheel, with my own spin of course (get it?). I wanted the buttons to still be under the wheel which should be no problem and I want to 3d print the parts for the clickwheel, keeping it as simple as possible. 

    Let me know if you've got any ideas

  • Handling the SD card and fonts

    Nic10/14/2023 at 06:27 4 comments

    Firstly, I've been trying out new fonts in order to support new characters and languages. Here is an example of a google font that supports Japanese characters. 

    Since the fonts are much too big to reasonably store on the flash they must be stored on the SD card. The flash still carries a basic antialiased latin alphabet font which is used if the font file cannot be found on the SD card or there is no SD card present.  Also, now if there is no SD card present on boot the homescreen will display a "No SD card" message momentarily every time you enter the homescreen.

    Ive also been experimenting with wireless file transfer with the excellent code from 
    G6EJD ( My test reveals that this system can transfer files at a speed of about 0.5 megabits per second. This is a very low speed for file transfers especially when you get into bigger music files. This system as it is would take an hour to send across 60 4 minute long compressed music files. I think i'm starting push the speeds of 1-bit SPI mode. An obvious solution to this is to go into 4-bit mode but I am not really comfortable on the software side. Even if I was im starting to dislike the wireless approach, having an sd card reader built into the board costs about a dollar in parts and means I can sidestep all wireless and 4-bit business. Simple usb mass storage drag and drop is really what I want, so I might as well built what I actually want instead of trying to make the cleanest most perfect solution. Also the wireless transfer is pretty inconvenient even if it was was faster and it only works when you have access to wifi.

    That makes the plan for the V3 as follows:

    -Add SD card reader chip with USB switch to switch between programming and SD card

    -When using card reader set the SPI pins as high impedance on ESP32

    -No wireless file transfer

    Id love to hear some opinions 

  • Sprites are pretty handy

    Nic09/23/2023 at 12:36 0 comments

    Spent 8 hours today on sprites with tft espi. Definitely worth it though as now there is no flickering when drawing lots of text items on the screen because they are all drawn at once. It also allowed me to add a text scrolling feature, so then when the file name is larger then a threshold it scrolls through it to display the whole file name. Then to wrap it up I added a file scroll thing on the side to display where you are in the list, looks pretty goo with antialiased graphics.

    Heres a quick demo:

  • Basic file explorer and music playback

    Nic09/16/2023 at 12:29 0 comments

    After quite a lot of coding there is some basic functions going, so far ive implemented:

    -file filter for non music or directory files, identify directory files with a /

    -scrolling main directory with auto adjusting scroll limits

    -playing files from main directory

    -current and end times for music

    -local file name storage to reduce sd card reads

    -music playing screen, when exiting it stops playback

    -temporary volume controls on fast forward and rewind buttons

    -All of the initialisation and button handling code


    -Clickwheel functionality

    To do

    -Directory navigation and treating directories like playlists

    -Checking files are playable before entering music player screen

    -Find out why current play time sometimes starts at 17 seconds

    -File name scroll for files that are bigger then max width (Had this working before but it slows down everything)

    -Volume with clickwheel

    -Hold switch

    -Other basic music player functions

    -Metadata from music files


    Heres the demo video of what i've coded so far:

    Im happy with how im starting to progress with the coding (Which I must mention is here, i'm really starting to make progress. I do feel that right now im holding back the potential of this device by being a hardware guy but I hope I can change this and learn enough to fully realise what I want to achieve with this project. 

    On another note, being with this device for a week now, i've realised how much of an impact haptic feedback has on the functionality of a clickwheel. You are scrolling a smooth surface with only visual feedback and it feels a bit weird, I think im going to wire in a haptic motor at some point and definitely include one for the next version. Big oversight to not include one on this version but thats part of the development process, learning from mistakes to make it better for the next version. 

    If I had to rate it, id say the audio quality is pretty damn good. Im listening through kb ear ks1 in ear headphones and cannot tell the difference playing through this vs any other device. Then again I don't have any high quality audio devices and don't listen to uncompressed music so I don't know. Im no audiophile but its definitely good for me. Ill have to figure out a way to record directly from it so I can send some files here side by side.

    Finally, don't judge the music files that are on that SD card.

  • Coding is hard but im making progress

    Nic09/11/2023 at 06:49 0 comments

    Encountered a couple coding issues which you can see below. Had problems with a for loop which was drawing the text but fixed it by replacing it with a while loop. 

    Now i've got the text all displaying correctly and it is scrollable with the clickwheel. However every time it has to draw the screen it needs to read the SD card again so there can be quite a bit of lag if you scroll fast which can cause it to skip items. To counter this I plan to store the displayed file names temporarily so the code can just read from an array instead of the sd card when it needs to update the screen, hopefully getting rid of that lag. A file filter also needs to be in place to only display music files. Then some more code to handle navigating folders and treating them as playlists. Once I figure out handling SD cards ill pretty it up and make it how I want it to be, obviously it shouldn't just dump the contents into a big list of music files. I think my next goal however is adding the battery and clock information and maybe some basic settings because I want an easy success, handling the SD card and making a gui is hard work.

  • Pretty hard for some 1s and 0s

    Nic09/10/2023 at 03:31 0 comments

    Software is always the most difficult part of a project for me as my coding skills are not the best. After a lot of figuring things out I have it displaying the file name from the sd card and playing it using arduino audio tools player class. 

    Ive also combined it with my menu code, here it is playing a 1khz test tone from the sd card

    Now comes the problems, I have no idea how to display all the filenames in a list. Ive tried it with the SD library for Arduino but it only gave parts of the filenames. I couldn't get sdfat to initialise the SD card either. Another issue is that anytime you refresh the display it will interrupt the audio playback. Im trying to get the audio working on one core and the display checks on the other core but it just doesn't work, at the end of the day they are both sharing the same SPI bus. It will either not work at all or the audio playback will be interrupted by display updates.

     Ive optimised the display code and adjusted the audio buffers but can't get it to work nicely together. So i'm stuck here for now until I can find a solution. Any help would be greatly appreciated.

  • Case and basic menu

    Nic09/07/2023 at 14:00 0 comments

    So I quickly designed a new case and it's working quite well. Feels really nice in the hand and fits all the components really nicely. I also coded up a basic menu that can be scrolled through with the capacitive touch wheel using the interpolated values. So it's now taking that degrees value that made the awesome wheel spin demo and running it through some logic to divide it into 12 interpolated segments. Unfortunately I don't have a video to share as the clickwheel connector broke so it needs replacing. Should have a video up by tomorrow hopefully. 

    In the meantime have this photo of the basic main menu, still needs some work and the battery percentage and time but I think it looks alright so far. Hoping to get a thinner text on there too. Although this text has anti aliasing so it looks amazing in person. The selected item is white and the others are a dark Gray though the camera screws it up, this is actually at 25% brightness just to get a clear picture.

    I think overall it's really coming together nicely. Now some people may not like the Zuney way the UI is going but that's a matter of personal taste and I sure don't have the software skills to be recreating an iPods software and UI. I think once I get some thinner text (segoe ui?) It will look really clean. I want to get the time and battery percent on the home screen too but making it a basic music player will come first. Let me know your opinions. 

View all 15 project logs

Enjoy this project?



GD wrote 09/07/2023 at 06:37 point

Very interesting.

"Add external capacitive touch sensing chip that can communicate over i2c and has an interrupt." 

Have you ever had an idea to use clickwheel from ipod classic? :)
Will schematic and code be open source?

  Are you sure? yes | no

Nic wrote 09/07/2023 at 07:47 point

To be honest I never really looked hard at that option and it definitely deserves some more looking into. I had heard of people using them for projects but just assumed they'd be expensive and a pain. I'll be sure to look at it for version 3, thanks for telling me about it. The code and hardware are currently on GitHub. Hardware is linked on this page and the current code I'm using is on my GitHub. I wouldn't recommend building this version though, don't get me wrong almost every part works and in theory you could build one but I would wait for the V3 so I can make it easier to assemble and build. 

  Are you sure? yes | no

GD wrote 09/07/2023 at 11:01 point

I am also working on a similar project.

For fuel gauge I plan to use LC709204 or LC709209F - Low Power Consumption 2µA.
For battery charging - MCP73871 with Load Sharing (it has a large list of features). "The MCP73871 device includes a low battery indicator,
a power good indicator and two charge status
indicators that allow for outputs with LEDs or
communication with host microcontrollers."
As the codec I consider ES8388.
And the MAX97220 amplifier.
But this is still preliminary.

  Are you sure? yes | no

Nic wrote 09/07/2023 at 13:21 point

That fuel gauge is quite expensive but I only buy parts off lcsc, same goes for the battery chargers. But if you can find them then you go for it. I chose the codec I did because it has some really good specs and it only costs $1. Good luck with your project, what are you making? 

  Are you sure? yes | no

GD wrote 09/08/2023 at 05:10 point

Thank you.

Аctually the same :)
I just have a case\body of ipod classic and I plan to make a player out of it. That's why I asked about clickwheel :) Somewhere on github there is code for connecting clickwheel from ipod. The main problem is finding a 2.5" display :))

  Are you sure? yes | no

Nic wrote 09/08/2023 at 06:05 point

Yeah 2.4" and 2.8" are the standard ones I see around. If you can go for IPS they really are great. Ive used which is more reliable for documentation then aliexpress. If you ever find that code please share.

  Are you sure? yes | no

Nic wrote 09/08/2023 at 08:38 point

Thanks for the github links they are some really nice work. Im really unsure at this point if im going to go with a clickwheel because it complicates the hardware a lot since theres really no gpio for it to hook up to and I have to deal with handling it. My favourite option at this point is to do another version of the custom clickwheel with easier assembly.

  Are you sure? yes | no

GD wrote 09/08/2023 at 08:49 point

Sure. You're right. 

BTW, I just found interesting link - 12-channel capacitive touch sensor:

Overview | Adafruit MPR121 12-Key Capacitive Touch Sensor Breakout Tutorial | Adafruit Learning System

This chip can handle up to 12 individual touch pads. I2C

  Are you sure? yes | no

Nic wrote 09/09/2023 at 02:39 point

Thanks, good to know one of the chips ive been looking at has been used by adafruit. Im looking at the:





It just has to be i2c, reasonable package and price with an interrupt

  Are you sure? yes | no

GD wrote 09/13/2023 at 12:51 point

"However every time it has to draw the screen it needs to read the SD card again so there can be quite a bit of lag if you scroll fast which can cause it to skip items"

What kind of FS are you using?

  Are you sure? yes | no

Nic wrote 09/13/2023 at 12:55 point

This is reading from a fat32 micro SD card running in spi mode. I need to point out that's just a result of the test code to read and list the files and not how it will behave. I'm working on the code to store files names locally so it doesn't have to be read on every screen refresh.

  Are you sure? yes | no

Erlend Ervik wrote 08/28/2023 at 15:05 point

Neat project.

There may be BLE headsets (there is a profile for it), but bluetooth classic ones would be easier to find.

ESP32-P4 looks very interesting, but not released yet.
Using two chips and just use one as wireless bridge is a option, unsure how friendly the ESP-EDF is in seting it up.

ESP32-PICO-V3-02 have 1 extra GPIO, and RAM+flash, QFN package. Useable?

What is the sound-quality like? I kinda expect it to be very good.

As for drag & drop files: is CIFS/FTP/.. server on wifi viable?

Worst case, you could use a USB to SD controller and just tri-state(set as input) all pins used for the SD interface when USB is connected.

  Are you sure? yes | no

Nic wrote 08/28/2023 at 15:27 point

Yes Bluetooth classic headsets are definitely more common so I want to support those.

 Using two seperate chips was thrown around as an option but I don't think it's really practical to be doing.

Yes definitely, it would be something to look into. At the moment I would like to stick to a wroom because the board is quite hard to assemble already and I don't feel ready to add another point of complexity when trying out the new version. Though after the next version is proven to be working I would definitely consider. Right now I can't see the advantage over the available modules though. 

 I don't consider myself to be an audiophile, so take this however you will. But my experience has been what I would call quite good so far. When there is no music playing there is no hiss that I can hear. When playing music from a MacBook and phone and comparing I can find really no difference. If you put me to a blind test I wouldn't be able to tell which was which. It is definitely good enough sound quality for me, though I'm not exactly experienced with audio. I'm really quite happy with the performance of the thing. If you wanted to know I've been testing with kB ear ks1 earphones, which aren't exactly hard to be driving. 

I think a wifi based file transfer is possible from my understanding. Software is not exactly my strong point though I see no reason why it isn't possible. If anything I want to avoid a companion app which would be needed for bluetooth. I want to avoid over engineering this.

This idea was floating around in my mind, I haven't really pursued it in any meaningful way yet although I bet it would work. I want to avoid the complexity of it if I can because I think it's just too much. I'd not only need the USB to SD card chip but also a USB switch or hub.  It's a can of worms im not looking to open until wireless file transfer is out of the equation.

Thanks for the questions and comments, really made my night. :)

  Are you sure? yes | no

allexoK wrote 08/21/2023 at 17:59 point

Wow, looks cool!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates