This stuff isn’t working right..


If it was so easy, everyone would be doing it.

Dream gets a little tougher when you have to wrap it around the necessary hardware. How am I going to fit all this stuff in here?

Putting everything together..

  1. BulletA screen for choosing songs.

  2. BulletHardware to actually play the songs.

  3. BulletSome sort of mass storage to hold the music.

  4. BulletAn amplifier to drive the speakers.

  5. BulletSpeakers. Well..

  6. BulletEarbuds for now.

  7. BulletA processor to run everything.

  8. BulletA 3D designed and printed case.

  9. BulletFigure out how control SD card.

  10. BulletWrite code for the .mp3 player.

  11. BulletPatch the .mp3 library to start faster.

  12. BulletTry to get some more sleep.

The first order of business was to get the SD card understood and under control. This is where the command processor came in. It made a really nice testing setup for SD commands. And, I could write the results back to the IDE monitor screen. I was able to get this working pretty well and had a lot of fun with it.

Independently, I’d written a really nice library to control the .mp3 player, in the background, without using pesky interrupts. This was one of those projects where you write a lot of code, cross your fingers, try it and it works right out of the box. I felt like a coding hero.

Then I find -  Most songs I encoded to .mp3 were taking 20..30 seconds to start playing. What the heck? They don’t do that on my Mac. What’s going on?

After a bunch or digging I find out about ID3 tags in .mp3 files. Apple uses them to store all the album artwork in the files themselves! The 20..30 seconds is the .mp3 player going though all this image data before it finds the music. ARRGH!! Who wants a Doorbell that takes 30 seconds to  start playing?

I”d posted about this on the Adafruit forum, they build the .mp3 player hardware I’m using. Their answer was along the lines of. “Well yeah, we saw that too..” I was on my own.

I had to learn about how .mp3 files are put together. And they are a nightmare! I swear they must have been designed by the IRS. All it did was give me a headache.

By now I’m spending all day 3D modeling parts and running test prints for the enclosure. Then spending all night writing code. LIttle did I realize this pattern would go on for about six weeks.

In the end I found a freeware application that would strip out all this stuff from your .mp3 files. Should I just fix the files? No, there’s a lot of files out there. I figured “The guy that wrote this knows how this works, I’ll ask him.” I emailed the guy that wrote the program. (Mark Verstraete)

And, totally cool of him, he replied telling me how it all worked and where to get info. etc. Thank you Mark!

Using what I was told by the Mark and some other bits I picked up online, I was able to write a patch for the Adafruit library that looks for the ID3 tag and jumps the file pointer past it. Works great! Now if they’d ever get around to merging in my pull request..

Cool! Smooth sailing from here on out.

<< Easy project     More broken! >>

When geeks tell you “Its really easy, really it is”. They’re lying. Working in the field, one runs across evidence everywhere that this is not the case. If it was so easy, why are so many hardware libraries so full of holes? Its because, at that time, who ever wrote the library was barley understanding what’s going on. “It worked? Cool! Close the box!” I know this because I’m guilty of the same thing. Sometimes after learning more, I go back and see what I’d done and wonder. “How did this work at all?”