Archive for the ‘musicplayer’ Category

Almost there…

Wednesday, July 21st, 2010

First the good news; I’m getting clearly recognisable audio output.

Now for the bad news; output a also clearly distorted and slowed down and I have no idea why yet. In the waveform below you can see what I mean. Just right of the middle is a flat piece in both channels. This goes on throughout the song. At the moment I’m not sure if this is the only thing wrong or if there’s more going on. For now my guess would be there’s something wrong with sending audio data to the decoder. Or data can’t be read fast enough, but if that’s the case the whole thing needs some rethinking as this is just a lowly 128kpbs MP3 file.

Update: DREQ has a duty cycle between 15 to 20%, so the decoder isn’t starved of data. Same goes for the SD card, it’s select signal is only active for around 11% of the time.

Hardware merge

Monday, July 19th, 2010

For the first time all components sit together on a breadboard (well actually 2 because the decoder board is so wide). And yes, things still work – UART, SDHC reading and decoder tests. Code wise things are also looking good. There’s still lots to do, but seeing less than 8kB FLASH and 850 byte RAM is used so far (without the FLAC patch) my current concern is speed. Doing a directory listing takes much longer than expected. Slow is normal at this stage (no 512 byte sector reading, dumping via ‘slow’ UART), but still.

The next step will be attempting to play a couple of songs, starting with a low bitrate MP3 up to a 50MB FLAC file. In the meantime, enjoy these two shots;

Something fishy

Saturday, July 10th, 2010

During the past week I’ve spend various evenings getting bluetooth communication and SPI (for the SD card/VS1053) to work, but thus far without success. Something fishy is going on and I haven’t yet been able to put my finger on it. I’ve been using avr-gcc (the one included in WinAVR and Debian testing) and results are unpredictable.


What the FLAC?!

Wednesday, June 23rd, 2010

It seems wanting to play FLAC files has some consequences. Because FLAC is lossless there’s a limit to how small the files get. Now that in itself is not a big problem, there’s enough space on SD cards these days. But the bigger the file, the higher the bitrate the controller has to pass on to the decoder. At the moment the ATmega328P is my controller of choice (why? because I’ve got a couple lying around) , but I’m not sure if it’s capable of processing high bitrates. Playing a random FLAC file on my laptop reveals an average(!) bitrate of 886 kbps. Playback was done from a 8GB class 4 SD card without problems, so if there’s a bottleneck, it’s the AVR.

Another FLAC issue is that the decoder isn’t in the VS1053′s firmware, one has to upload a patch first. It’s a 60KB patch. Of course the 328 doesn’t come with that much space, so it’ll probably end up on SD card as well. It would mean some extra firmware code to read it from the card and upload it to the decoder after power-up, but that shouldn’t be that difficult. The (compressed) FLAC patch is 60KB…. as C code. Actual binary size is only 6226 bytes. And guess what, that would probably fit very comfy in the 32K flash of the AVR. Cheers!

Hardware player

Sunday, June 20th, 2010

The player is where most functionality is located. Features currently in the pipeline are:

  • Playback of at least MP3, Ogg Vorbis and FLAC;
  • Audio is read from SDHC cards, FAT32 formatted;
  • Can be controlled without a direct line of sight, e.g. bluetooth based communication;
  • Can receive (learn) and transmit IR signals to control AV equipments (optional);
  • Can be used independent of other hardware;
  • Silent operation;
  • Low power usage (maybe use a small solar panel?).

The audio decoder I’ll be using is a VS1053b from VLSI. This is an expensive little chip (16 euro), but well worth it. The alternative would probably be using a DSP writing your own DSP routines taking up a lot of time. Not something I’m looking forward to. In the past I developed an USB board that required writing your own USB device code in assembly. A couple of months later FTDI Chip came out with their brilliant USB chips that include a protocol engine. These ended up in the USB2LCD devices made during my LiQuiD-MP3 days. The difference in development time is huge and keeping this in mind, VLSI chip is by far the best option.

Music will be stored on an SD card. Other considerations were a network share and USB harddisk. Using a network share would violate the independent usage requirement and a harddisk uses too much power and makes too much noise. This means music has to be stored in the player. Although other flash media could be used, SD cards have the advantage of having a SPI interface. I’ve got a couple of Compact Flash cards lying around, but connection those would be more problematic compared to SPI.

To control the player bluetooth was choosen. Bluetooth used to be difficult and expensive, but recently bluetooth serial bridge modules have been popping up costing around $20. Almost every controller out there has an UART and being a bridge means you don’t have to fool around with the bluetooth protocol itself. Another reason for going this route is (theoretical) throughput. Since the player has no user accessible controls and I do want to be able to select tracks, song information has to be transmitted to the remote control unit(s). Somehow I don’t think RF modules would be up to the task. Besides I have plans for the Pandora which already has bluetooth onboard. Would be pretty pointless (and ugly) to add additional hardware to it.

That’s it for now concerning the player. Will post more details as they pop up.