*.wav playback on pic

[SMUGangsta]

Hi

I am working on a project that requires audio playback, from a pic.

I have collected a few circuits from around the 'net, but I wanted to hear from someone who has tried it.

The project will stream a 10 ~ 20 min wave file from an SD card to the pic for playback.

What can I expect quality wise - is CD quality a possibility?

Im hoping for 16bit, stereo, 44200Hz play back, would this be possible on a midrange 16F pic - i havnt chosen one yet, but it'll be one with 2 hardware pwm modules.

also all the circuits i have seen run a small 8Ω speaker, but i need to provide stereo LINE level outputs (1v peak to peak i think?), how would i connect the phono sockets to the pic - ive never done an audio project before.

many thanks

 

[Someone Electro]

I done such a thing and I can tell you no way you are getting cd quality out of a 16F. CD quality needs about 1,7MB/s bit rate. For something running at 5MIPS that's not very possible. Also you need a bit of buffer because jumping between sectors takes time.Then also even with a 120Mhz pic can do 8Bit acuracy on PWM with the 100Khz pwm freqency.So I recommend you use a PIC33F with a internal DAC. Its DACs can do 16bit 100Khz, has line level outputs and its own buffer.

 

[SMUGangsta]

I done such a thing and I can tell you no way you are getting cd quality out of a 16F. CD quality needs about 1,7MB/s bit rate. For something running at 5MIPS that's not very possible. Also you need a bit of buffer because jumping between sectors takes time.Then also even with a 120Mhz pic can do 8Bit acuracy on PWM with the 100Khz pwm freqency.So I recommend you use a PIC33F with a internal DAC. Its DACs can do 16bit 100Khz, has line level outputs and its own buffer.

glad i found that out before i got too far, wil the pic33f do full cd quality sound, wired as you have described above?

how did you work out 1.7Mb per sec?

i calculated 16bit(2 bytes), stereo(2 bytes), 44200Hz

so thats 2x2 = 4 x 44200 = 176800 bytes / 1024 ≈173Kb per second

thanks

 

[Daniek]

hey

It's bitrate, not byterate. You need 16*2*44200= 1414400

By the way, B is byte, b is bit.

Daniel

 

[Ubergeek63]

I would assume you want to be able to get the file from a PC... this topic comes up periodically. if you want to be able to read a memory card written to by a PC you need to read a FAT formatted MMC.

If the chosen micro can not do this and send the data to the DAC or PWM fast enough you can not play a .wav

 

[SMUGangsta]

hey

It's bitrate, not byterate. You need 16*2*44200= 1414400

By the way, B is byte, b is bit.

Daniel

So its 16bits (Audio)
x 2 (because its stereo)
x 44200 (because thats my chosen samplerate)
==========
1414400 bits per second

divide by 8 (convert bits to bytes)
==========
176800 Bytes per second

divide by 1024 (convert to KiloBytes per second)
==========
172.65625 KiloBytes per second


^^^^^ is that right or wrong?

Also can someone help me with this bit.

also all the circuits i have seen run a small 8Ω speaker, but i need to provide stereo LINE level outputs (1v peak to peak i think?), how would i connect the phono sockets to the pic - ive never done an audio project before.

Ive been on the microchip site, but cant seem to find anything suitable, so how bad would 8bit,stereo,44200Hz sound, as there are not many parts with 2 16bit pwm.

Its either that or a dsPIC33FJ128GP802, which is probably overkill.

Other suggestions are welcome, for example specialist audio playback chips - the most important thing is that it is quite good quality (its going to be amped up via 1000w amplifiers), and that I can syncronize with it, eg at a specific time during the music the circuit needs to switch on a relay or transistor, with a resolution of 10ms.

Its not a stage lighting system, but that would be the best way to describe it - when things happen in the music embedded codes turn on lights etc (or sycronised start and maintain timers with the music)

A chip that could handle MP3 would probably work too - as long as I could extract the tags, and possibly generate an interrupt when it reaches them.

 

[Someone Electro]

Oh sorry yes i messed that up( i was saying that from memory) It is 1,4Mbit/s or 173 KB/s. And no a 33F is not a overkill. You need a fast pic to handle those bit rates and handle the FAT16 file system at the same time. Also its good to have a few KBs of RAM for making a tiny buffer that is needed to provide a very constant stream of data to the DAC.

As for making it play mp3s you need a external decoder IC for that.(beware that all of these ICs are SMD only and may be hard to find) But useing that means the PIC dosent need to work as hard. Since mp3s are normally only 128 to 300kbit while CD quality wav is 1400kbit. mp3 will also cause a slight deterioration in sound quality since it makes compression losses (Those compression glitches can sometimes be quite heard on big concert speaker setups) But if you plan to convert mp3s to wav and then play them with the pic then you already lost true CD quality in the inital mp3.

 

[Ubergeek63]

it is virtually impossible for a pic to do it outright. your best bet, if you insist on not using a codec, is to put a 1Kx32 FIFO out there and simple R/2R ladders for your DACs. Then you can hammer out the data bursts and let the FIFO run at a constant rate on the output side.

Of course it is much less expensive to just get a codec...

 

[Someone Electro]

Nope you dont need all that.

A PICs integrated DAC works at 16bit 100Khz with 256 oversampling (that means it creates 256 data points between each single sample and so smooths the part between samples out in a nice line instead of a sudden jump to the new sample) also it has its own buffer that takes a prescaled clock from the instruction clock and can create programmable interrupts to the CPU on top of it all the analog part of the DAC runs on a separate analog supply so there is less noise. So all this ensures a microsecond precise timing of the samples with a smooth noiseless signal.

 

[Ubergeek63]

Nope you dont need all that.

A PICs integrated DAC works at 16bit 100Khz with 256 oversampling (that means it creates 256 data points between each single sample and so smooths the part between samples out in a nice line instead of a sudden jump to the new sample) also it has its own buffer that takes a prescaled clock from the instruction clock and can create programmable interrupts to the CPU on top of it all the analog part of the DAC runs on a separate analog supply so there is less noise. So all this ensures a microsecond precise timing of the samples with a smooth noiseless signal.

Which one? I have yet to see a spec on one that will do that. The claim is a bit suspect since even the Microchip site has no mention of the capability and the ONLY app note that mentions audio uses an EXTERNAL audio codec chip.

 

[Someone Electro]

For exsample the dsPIC33FJ128GP802 is one of them dsPIC33FJ128GP802

Along that it has some impressive specs for a 28 pin pic, like 128K of flash 16K of ram 40 MIPS , 5 serial ports, parallel bus, DMA, RTCC etc

So a nice pic in cases where you need lots of processing power but not that many I/O Nice for audio as well with its DAC

 

[SMUGangsta]

its looking like an external chip is the way to go - if i want quality!!

im just thinking about the embedded triggers just now and could use a little advice.

i want to embed a single byte of data at various points within a wav file - stuff i found on the net was not relevant - so could i use my software, that is designed to prepare the wav file - to go through each sample, and convert any 0xFFFF (16bit) into a 0xFFFE.

Then embed my trigger as a 3 byte sequence - eg 0xFFFF (no longer in the wave file) - indicates a trigger follows?

the idea being that when the pic encounters a 0xFFFF pattern, it triggers the event based on the next byte, and does not pass these 3 bytes onto the external chip.

any ideas if this would work, if not why, or a bettter way to embed up to 256 'triggers' into a wave file

I have wrote a program that prepares

 

[Ubergeek63]

For exsample the dsPIC33FJ128GP802 is one of them dsPIC33FJ128GP802

Along that it has some impressive specs for a 28 pin pic, like 128K of flash 16K of ram 40 MIPS , 5 serial ports, parallel bus, DMA, RTCC etc

So a nice pic in cases where you need lots of processing power but not that many I/O Nice for audio as well with its DAC

That will do it...but not because the PIC can keep up with the data rate, because the DMA will do ALL the work.

Once the FAT crap is figured out playing the file is DMA transfers from SPI to DMA buffers and DMA buffers to the DACs...that is assuming it can not keep up direct transfers with out double buffering. Direct DMA from SPI to DAC might work on contiguous files. Any fragmentation will have to be handled in software, forcing the use of buffers to give the software time to find the next block.

 

[Blueteeth]

I've done 48Khz at 16 bit with a 16F....but of course only using an external I2S DAC (only available as SMD, and expensive compared to the PIC). The PIC was only there to move data from SPI flash to the DAC as and when I needed it....very simple logic, but so quick its tough to do it with interupts.

All depends on cost, repeatabilty, and whether you'd like a 'one-chip solution'. Its easy to go over-kill in these situations. (DSP's, FPGA's)..but tough to find something user friendly to design with.

Blueteeth

 

[Someone Electro]

Yes but interfacing a SD card is not that simple since the interface to the card wants CRC checks and various commands. Then on top of it is a FAT16 file system that might split 1 wav file in to 1000s of parts across the entire card. Thats a big pile more work for the PIC than reading a SPI flash chip from beginning to end by just clocking the data out in bulk transfer.

And no you don't need any extra chip to play CD quality from a SD card. A PIC33F can do it with nothing else but 2 capacitors on the DAC for DC removal. You only need one for playing MP3s (PICs are too slow to do that in software for a respectable bitrate)

And if the source of your audio are mp3 files you already lost CD quality since mp3 compresses it in a way that it distorts audio. Best audio compression method is proabobly ogg, its a bit bigger than mp3 but you get no loss of quality. PCM formated WAV is also no loss of quality but since its not compressed at all its file size is huge.

As for your triggers it might also be good if you put it in a extra file.So you leave your wav intact but have the triger wrote in a extra file with the same filename (but with like *.trigers on the end) so the PIC finds the right ones. And then write in the file the trigers and between thenm how many samples(thats wav files samples played) of a delay is needed til the next trigger. That way you still have triggers but leave the wav intact. Also you can add stuff to the end of the wav file and it will still be playable.

 

[SMUGangsta]

What about if i kept the SD card internal to my project, that would eliminate the fragmentation, and processor cycles required for handling the filesystem. Basically as a large & CHEAP storage medium. The idea would be to just impliment a mmc/sd erase/read/write interface and program it with a cable direct from the computer - in the same way you would program a chip.

That would allow the pic to transfer data very efficently to the DAC, as it would be in exactly right format, and in the right order.

Im thinking that i dont need to store the wav header, as i know the format the data will take. Also i may store my trigger table at the start off the wav file, it has a fixed length so my pic can skip directly to the start of audio data.

EDIT: just looked at the DMA section in the datasheet,

so the way that works is - a byte is recieved on spi1, as soon as it is recieved, it triggers an interrupt which the DMA controller picks up, causing it to tranfer the newly recieved byte directly to the DAC then repeats this cycle - all without any input from me (apart from setup) is that right or am i missing something really crucial because it sounds to easy

 

[Someone Electro]

Well ditching the file system would reduce the CPU load but you still need a buffer because the data will go out in 512 byte chunks (for cards <2GB, 4GB cards have 1024 byte sectors) and the card has a little seek time between sectors also the trasfers have CRC checks.

But i recommend you keep the file system because a PIC is fast enough. Also you get the entire code for handling FAT12,16 or 32 from the microchip website it even includes the code to interface to a SD or CF card or even a IDE harddrive .

and a DMA can be used in a better way than moveing data from SPI to DAC. What you can do with it is make a 1KB or so buffer and have the DMA listen for the DACs interrupt that signals it can take more data.Then you simply write the file in to that buffer and have the DMA automatically feed data to the DAC.