[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] sound_handler and threading

From: strk
Subject: [Gnash-dev] sound_handler and threading
Date: Mon, 10 Nov 2008 09:30:34 +0100

You may have noticed make check still fails
on a buildbot (mx1).
This is because mx1 host has no sound card,
so SDL_OpenAudio fails, and the SDL callback
*never* arrives.

Now, our problem is that the core lib relies
on the assumption that sound will be fetched
at regular intervals, while SDL doesn't guarantee

We have two options here:

1) force SDL to always fetch sound at regular
   interval (starting our own thread if the SDL
   one doesn't start).

2) have sound fetched in main thread on core

Option 2 has the advantage to drop another forced
thread in the core. The main thread might be filling
a queue for the system mixer to consume, in whatever
way the hosting application decide to use (threading
or event...). To allow threading, the only thing to
mutex-protect would be the samples queue. Downside
would be that if libcore is too slow in pushing samples
we'd have a sample buffer underrun and if it is too
fast we'd have an overrun (or we'd grow the queue
in unexpected ways). Both occurrences (underrun and overrun)
would need to be signalled somehow back to core for
triggering some synchronization mechanism.

Option 1 will require us to have NullSoundHandler also
spawn a thread for fetching samples. And we'd need to
implement a TestingSoundHandler for manual fetching.
(the TestingSoundHandler would not be needed in option 2
as the NullSoundHandler would just consume all samples
on ::advance, from a libcore callback).

Comments ? Ideas ?


 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]