Since the release of the Palm Tungsten T, Palm Inc handhelds have the capability to play back WAV files(aka sampled sound). I have recently implemented such a sound routine and found an interesting twist(due to MemGluePtrNew not working)…and felt like sharing it with you!
Essentially, sampled sound works by repeatedly calling a function and requesting that it outs wave data into a buffer, from where it is then played. The main problem here is that the callback must execute quickly and should not loose any data(frame skipping). “Wrapping around” the end of a RAM buffer can be tedious both code and performance-wise, but the Palm OS has a little-úsed but very useful feature called a file stream.
The function below is called to start the music:
//Check if data really is UINT8
//Write to buffer
Essentially, it creates a new file stream, opens each of the “bits” of sound in the application database, and puts it all together into the file stream. It then creates a new stream and starts it. BTW, FileWrite’s documentation in PODS is wrong…but more on that later.
The music gets ended by this call:
//Clean up buffer
This first stops and deletes the stream, and afterwards cleans up the buffer.
Last but not least, here’s the callback and the global data struct:
//Contains all data that the sound stream callback needs
UInt32 framesdone;//aka where to start copying
static Err SndStreamBufferCallbackFunc (void *userDataP, SndStreamRef stream, void *bufferP, UInt32 frameCount)
//Write data from buffer
The sounddatat type gets passed to the callback each time the sound manager needs data. It contains all information needed to generate the next block of data. The err!= filecount bit of code is used to determine if we “ran over the end” of the file stream…if we did, the stream is rewinded and reading commences once again from the beginning to fill the buffer up completely.
What do you think?