Archive for the ‘audio decoder’ Category

S/PDIF is here to stay

Sunday, September 19th, 2010

With playback working again it was time for another addition; digital out. After some soldering and enabling I2S on the decoder the setup was ready for test run. Hooked the monster up to an Onkyo receiver and voila.

First some details. Currently the VS1053B is configured to output a samplerate of 48 kHz (this is also the highest supported samplerate for all codecs). This goes directly into a CS8406 S/PDIF transmitter which is wired in hardware mode. A second option would be a 96 kHz I2S signal. Even though the decoder support 192 kHz it can only output it with MCLK divided by 2. The CS8406 only supports clock ratios down to 128 * Fs. For 192 kHz to work it must go down to 64 * Fs.

At the moment it only uses TOSLINK, but the final version will also have coaxial output. It’s just that I don’t have the required pulse transformer lying around.

Back to the receiver. It detects the output as a 44,1 kHz PCM signal. For a more isolated test I hooked up AKG K 701 headphones which is know for it reference like quality. And wow, what a thrill. This was simply the best sounding audio I’ve ever heard not coming from a real CD.

I could still hear some things I didn’t like (high tones), but at this time it’s unknown what the cause is. Could be the recording itself (need to compare with original CD), it could be samplerate conversion (48 kHz to 44,1 kHz), could be the setup (just think of how anal audiophiles can be about the smallest things ;)), etc. Just a matter of proper testing, listening and comparing.

Also one thing that’s bothering me is the interference the setup has on my cable TV signal (doesn’t affect HDMI). At the moment I’m just blaming all the breadboard wiring which probably acts like a small transmitter. The board is located almost directly below the inputs of the TV and since the cable signal already is very weak (some stations are half snow even without any other electronics close by), so it’s not directly a problem (not to mention the lack of programmes worth watching… but that’s another story ;))

Did you hear something?

Saturday, September 18th, 2010

The moment of truth has finally arrived; FLAC playback! After going through all the trouble of switching over to a Cortex-M3 controller and SDIO, this is a pretty gratifying moment :D

On the right you’re seeing SD card access reading 512 byte sectors (yellow) and the DREQ signal of the decoder requesting more data (blue). Playing is a 886kpbs FLAC file and just look at the space in between. That means there’s a lot of room for additional functionality.

Some quick notes about clocks;

  • SPI is running at 9 MHz
  • SDIO running at 7.2 MHz
  • Decoder running with recommended 3.5x multiplier and 1.0x addition

Well I’m off listening to some test tracks :)


Tuesday, July 27th, 2010

Couldn’t resist and upload the FLAC patch to the VS1053b. Tried the lowest bitrate I could find (877kbps) and started playback. Guess what, it played. Not fluently though, SPI transfers went through the roof and DREQ was active 100% of the time, so it wouldn’t respond to anything. But hey it played better than expected!

Hmmmz… AVR ¬†running @20MHz @5V, add a couple 10+ MHz logic level converters and see what surprise that brings… just sounds a whole lot better after this little experiment :)

I don’t think she can hold much more Captain! She’s gonna blow!

Sunday, July 25th, 2010

It was doubtful from the start, but by now it’s becoming increasingly clear the AVR isn’t going to cut it when it comes to playing FLAC. It’s close, but even at 20 MHz it’s likely any peaks in bitrate will ruin the party. Since Friday I’m been throwing various MP3 and Ogg Vorbis files at the decoder while monitoring data requests.

While all files played fine some variable bitrate files occasionally showed peaks of over 60% at 256kbps. Now take a FLAC with 4 times the bitrate; 1000kbps (average!). In the current setup the AVR runs at 8MHz. Max speed available is 20MHz, only 2.5 times the current speed. Due to the nature of average bitrates, one can’t predict the exact numbers, but you’ll have a pretty good idea of how this is going to end. Maybe with some clever programming and optimisations it could be done… maybe.. could… Don’t know about you, but I don’t like those words. Would be nice to know where the limit lies in reality, so who knows, maybe I’ll give it a go one day.

Time for plan B. Next post, so check back soon.

Let’s dance!

Friday, July 23rd, 2010

We have lift off! Reading the datasheet has once again proved to be the key. The SCI_CLOCKF register is initialised to 0×00 at power up. This means the decoder’s DSP is working at 12.288MHz with a max SPI write speed of 3.072MHz. The result is 2 fold; either the DSP hasn’t got enough decoding power and/or data transfers go out of sync. The ATmega328¬† is using it’s max SPI speed of 4MHz, roughly 1MHZ more than the decoder. You don’t have to be a rocket scientist to imagine this is a disaster waiting to happen.


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;

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!

Sine test

Sunday, June 20th, 2010

More good news! Hooked up the VS1053 to a buspirate and digiscope to see if I could send commands via SPI. It took a little fiddling getting the clock/data signals right, but the result is looking good.

This is just a small test using the VS1053′s build-in sine test, but it means communicating via SPI is understood and output works. Something I’m not happy with yet is the minor distortion in the signal. I have no idea if this is in the decoder, the scope, or just random noise due to the shaky breadboard setup.