[SDL] callback issue

[Scott Harper]

What I do is (I have a video editor I'm making) I have a thread grab  
and decode audio samples, and then I have a loop which keeps track of  
the current audio sample and has a marker for the first unwritten  
sample, then I write as much as I can of that sample to the audio  
buffer and update the marker.  If the marker is the same as the  
length of the sample, then I've written everything in the sample, and  
I grab the next sample from the thread, and continue writing to the  
audio buffer if necessary.

It's a rather complex loop for what it does.  If you need some  
pseudocode let me know and I can do that.  But I have an essay to  
write now so I'm going to hold off unless you need it. ^_^

-- Scott

On Apr 30, 2007, at 9:07 AM, <chris.2.dobbs at bt.com> <chris. 
2.dobbs at bt.com> wrote:

> Ok, thanks that kindof makes sense to me. Currently I do this in my
> callback routine
>
> void audio_out(void *userdata, Uint8 *stream, int len)
> {
>
> Lock internal data queue
> Pull off queue len  bytes of PCM data into data_p pointer
> Call SDL_MixAudio(stream, (const Uint8*)data_p, len,  
> SDL_MIX_MAXVOLUME)
> Unlock internal data queue
>
> }
>
> My internal data queue is populated by another thread which  
> receives AMR
> data via network, decodes it to PCM and stuffs onto queue ready for  
> this
> callback to playback.
>
>
> Are you saying that I need to get the callback to play slightly before
> the start of the next queue block retreived?
>
> Many thanks for your help by the way!
>
> -Chris
>
>
> -----Original Message-----
> From: sdl-bounces at lists.libsdl.org [mailto:sdl- 
> bounces at lists.libsdl.org]
> On Behalf Of Scott Harper
> Sent: 28 April 2007 18:25
> To: A list for developers using the SDL library. (includes SDL- 
> announce)
> Subject: Re: [SDL] callback issue
>
> As far as I'm aware, the audio hardware on different systems will ask
> for different amounts of audio data each callback, so your
> responsibility is to provide it with however much data it asks for.
> Often (for me, at least) this has meant playing through the end of one
> sample/source and starting the next one just a little bit before the
> next callback.  It's not clean, but the result sounds nice anyway.
>
> -- Scott