[SDL] Converting OSS sound code to SDL ...

[Loren Osborn]

--- Stephen Anthony <stephena at roadrunner.nf.net>
wrote:
> On August 13, 2002 05:54 am, Ryan C. Gordon wrote:
> 
> > > Guess what I want is a way to simulate
> write(...) to the soundcard,
> > > and only send stuff to the card when a write is
> done (and under my
> > > control).
> >
> > Keep a buffer of data somewhere. Call
> SDL_LockAudio() when putting more
> > data into that buffer, and SDL_UnlockAudio() when
> you are done putting
> > data into it. (Lock/UnlockAudio guarantees that
> the audio callback
> > won't run...do NOT use it for extended periods of
> time! Just as a mutex
> > to prevent race conditions. Do not call LockAudio
> from inside the
> > callback, either.)
> 
> Yes, that is what I'm doing now.  As an experiment,
> I set up a mutex (of 
> sorts) and 2 count variables.  In between calls to
> SDL_LockAudio() / 
> SDL_UnlockAudio(), I update the sound buffer
> (separate code to do this), 
> set the mutex to 1 and increment a variable that
> counts how many times 
> the buffer was updated.
> 
> In the callback, I check to see if the mutex is 1,
> then copy the buffer to 
> the SDL stream, set mutex to 0, and increment a
> variable that says how 
> many times the stream was copied.
> 
> All things being equal, the 2 counts should be the
> same at the end of the 
> run.  But they aren't.  There are approx. 4 times as
> many attempts as 
> there are actual updates to the stream.  In other
> words, only 25% of the 
> sounds I process are actually sent to the soundcard.
>  This would 
> definitely explain the dropouts I'm hearing.
> 
> Problem is, I don't know what causes it.  Is the
> callback 'atomic'.  That 
> is, while it's being called, it can't be called
> again (from the sound 
> thread)?

Unless it's recursive, it should not be called again
until it returns.  But it is in a seperate thread, it
won't be at all in sync with the rest of your program.

> 
> I'm really lost here.  The mutex is set to 1
> whenever the buffer is 
> updated.  The callback seems to not 'see' many of
> these changes.  So 
> maybe the callback isn't being called often enough??

For me anyway, it is much easier to to think of the
mutex being "locked" or "unlocked" rather than 1 or
0...

The point is the callback isn't called in sync with
any part of your program, so you should probably make
a mutex-protected ring buffer... The callback can read
out of it, and the rest of your sound code can feed
it... When it becomes empty, the callback should send
the silence value.

> 
> > As the callback runs, feed SDL as much data as it
> wants. If you don't
> > have anymore data, feed it silence.
> 
> How do you know how much data "SDL wants"?  And how
> to you feed it silence 
> (I assume by memset'ing 0 to the stream)?


The SDL_AudioSpec structure has a member value called
"silence" that indicates what silence value to write
to the stream.

> 
> > This is a different paradigm than direct write()s
> to /dev/dsp, and your
> > code needs to be adapted to it.
> 
> Problem is, I'm not sure how to do that :)


Hope this helps,

-Loren



__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com