View Full Version : Fast .wav Playback?
11-16-2010, 01:03 AM
I am completely new to Propeller and want to use it in a project where an input signal will have a .wav file stored on an SD card play as quickly as possible. I would like to use 16-bit wav files at 44.1kHz playback. The wav files only need to be about 2 seconds long, but I need a dozen or so ready to be played relatively instantly.
Is my project feasible? Would it be possible to have the SD load the files into some sort of DRAM before they are needed for faster retrieval? Obviously it's possible but 16-bit DRAM doesn't seem too common...
In case you couldn't tell, I'm really new to this stuff and have virtually no idea what I'm doing. :lol:
11-16-2010, 01:10 AM
Yes, the propeller can do this easily - see the object exchange (OBEX) for the FSRW object to interface an SD card - the files for that include wav players also. Kye also has objects for this in the obex as well. You will need a pull-up resistor, an SD card socket, a cap/resistor for the DAC output and an audio amp of some sort.
Another approach is the propeller based EFX-TEK board made by John Williams (nee MacPhalen) that plays very high quality audio files as you specify with excellent sound and good amplification. This one is already made and has support for it.
11-16-2010, 01:10 AM
No need to preload -- you don't have the memory, anyway. My company (EFX-TEK) created a commercial WAV player based on the Propeller and customers frequently comment that they love the "instant" playback of files (even though they're stored on an SD card).
Many of us have written WAV player code, so you've got lots of material to start with.
John Williams (nee MacPhalen)
John Williams is the famous guy (Star Wars composer) which is why I am forced to use my family name, McPhalen. It's an honor, though, as my grandfather, Earnest John McPhalen, was a musician before an industrial accident cut short his career in show business.
11-16-2010, 01:31 AM
That's great, thanks for the files.
I would also like to implement polyphony, but I know that can get tricky. I figured with 8 cogs it should be possible to do three of four of my short wavs at a time, but I don't know if it is possible with the object you have provided.
Thank you for the fast responses!
11-16-2010, 01:36 AM
but I don't know if it is possible with the object you have provided.
It's not. In my code you need one cog for the SD card, one to play the buffers, if noise is an issue then one for Chip's StereoDuty, and, finally, one for stuffing the buffers though this could be removed if you play a single file "inline."
Have a look at all the available code samples; you'll see there's a bit of work to play a WAV file.
There have been experiments by some to play two files at once, though I've not worked with that code.
11-19-2010, 04:04 AM
I've looked at the codes and I don't understand much of anything since I am new to this syntax, so I guess I'll order the beginner's kit and start with the tutorials until I get a good grasp of the language.
I have done some reading on how a wav formats are stored on SD cards and how the SD card handles its data, and I think I might be able to achieve mixing by putting all my sounds in one file (the sum of the individual file sizes is well below the wav file size limit) and making a list on one of the cogs of where the different sounds start in the chunk of the file and their duration, so that I can just have the one file buffered and pull the parts I want out to play. I think that since they are in the same file that I will be able to grab samples from different places in the file and add the individual samples together before outputting them in order to combine the sounds.
I understand that each cog can output a frequency that doesn't interfere with whatever else it's doing. Can you use the samples from the file to modify the frequency of a cog's output in to have a FM output?
Sorry for all the questions and possibly ignorant-sounding conjecture, I just want to know if any of these ideas are remotely feasible.
11-19-2010, 11:28 AM
Does this software have the anti thump setups?
(I am at work and can't download yet)
11-19-2010, 02:21 PM
@Toby: No, my code -- and I believe similar programs written by others -- read and play the data as is.
That said, I made a recent change to the AP-16+ so that it ignores metadata appended to the end of the file. I had never seen this but a customer sent me a file that did indeed have it. The WAV header gives the size of the audio chunk so I use that instead of playing through to the end of the file.
11-19-2010, 05:41 PM
I seem to remember you talking about the start and stop values of the counters, so that the initial jump up to 50% - playfile - drop to 0% again didn't cause the thumps on the audio on every play/stop. I am ok with the level lurches on initial switch on and switch off but if the levels were kept up at 50% all the time then it would be useable.
I tried a .wav player before (unsure which one) and it had these thumps and a background whine so it was unsuitable for my use. I need to have a "bell ring" for 2-3 seconds and the an automatic re-cue for the next demand.
11-19-2010, 07:11 PM
It's important to keep the DAC running and not turn it off between files; the initial thump comes from charging the the RC DAC circuit. I have some work that I'm going to be doing soon and may try a slow charge after the pins/counters are setup. The way my code works, though, this change would actually take place in Stereo_Duty as that is where DAC control resides.
11-19-2010, 08:08 PM
At the moment we have CD players on cue 24/7, the decks do not last long. They are thinking about solid state alternatives (£500-1000) so a little Prop project will show the folly of their ways.
A slower ramping up to the half way point would help.
11-20-2010, 05:39 AM
I really can't figure this bit out.
I requested 16-bit resolution at 44.1kHz sampling playback, but after learning a little more about what exactly that means, I've realized that it would require a sampling period of 22.7 microseconds with values whose period uses 1/65536 of the sampling period. How can the output possibly have that kind of resolution within that sampling rate?
11-20-2010, 08:32 AM
At 44.1KHz a parallel amount of 16 bits is sampled/requested, all at once. It is not 44100x65000 bits/sec, it is 44100x(one 16 bit word). This would come off the SD card as two 8 bit bytes.
11-20-2010, 05:01 PM
@HMSTL To play a 16-bit WAV file you do have to update the output DAC(s) every 22.67us (with a 16-bit value). This is why the WAV players for the Propeller use a buffering system. One cog fills the buffers with data pulled from the SD card while a second cog plays the data at the fixed sample rate.
11-20-2010, 06:30 PM
The 16 bit value can be anywhere from 0 to 65536...
What kind of output does this produce that can deliver 16-bit resolution in 22.67 us?
11-20-2010, 06:45 PM
That 16-bit value is converted to a signed 32-bit value and written to one of the Propellers counters (FRQx register) that is running in Duty Cycle mode. The output pin is connected to an RC circuit which converts this signal to an analog voltage. What you may be missing is that we're getting a hardware assist from the Propeller's multipurpose counters.
11-20-2010, 07:30 PM
That is definitely what I was missing. Thank you so much. Those counters were exactly what I needed to look up. I can't understand the specifics yet, but they are definitely what I need...
These buffers are a sort of small-scale preloading, aren't they (just for sections of samples)? So that you can feed the values to the counters continuously, right?
11-20-2010, 07:50 PM
Yes. In the assembly code that feeds the samples to the DAC the main loop is set to the file's sample rate. There is plenty of time, when using PASM, to read a sample, make volume adjustments, and output the samples (left and right) to the DAC. With 16-bit files you get both channel samples in one hub (where the buffers are) read (using a long).
John A. Zoidberg
11-23-2010, 03:04 AM
I'm trying your *.wav player, but I can't get to have any output at all.
Is there any exact diagram of an SD-card (not microSD) connections? I may missed out something in the connection of the SD card to the Prop.
Also, what R/C values on the DAC should I use? Thanks.
11-30-2010, 05:01 AM
page 3 on
I hope this helps. If I understand correctly, you need the resistors and all of those connections except for the SD_CD and SD_WP.