El dc 23 de 04 del 2008 a les 10:11 -0400, en/na Albert Santoni va escriure: > Hi guys, > > I've got a question that I haven't been able to conclusively answer, and > I was wondering if someone could shed some light on an answer. > > When a buffer underrun occurs, what happens to that instance of the > callback thread? > > To elaborate, consider a case where the soundcard has requested audio, > so the PA callback function gets called and your program runs off and > processes whatever audio it has to as quickly as it can. If your program > can't process quickly enough, what happens exactly? Does the initial > callback thread get killed, and another one started immediately after? > Does another callback thread simply get called? > > The reason this concerns me is because if the callback thread gets > killed (if that's what happens during a buffer underrun) while it is > waiting on a mutex, I'm afraid it could leave the mutex in some > undetermined state, deadlocking my application. > > If anyone could offer any advice or insight, it would be much > appreciated. > > Thanks, > Albert
I've always guessed that in that case the audio process terminated somehow. Being curious about it i've looked at PortAudio code to see the details. (this code from track corresponds to an old version, but i guess that the same technique also applies to the trunk) http://www.portaudio.com/trac/browser/portaudio/trunk/pa_unix_oss/pa_unix_oss.c?rev=115#L563 So what happens is that a watchdog thread running with higher priority is set up and it kills the audio thread ONLY if it is reading/writing audio from 3 seconds behind the audio driver time. Ok, but during these 3 long seconds you can have underruns anyway. What i _deduce_ is that while in this 3 sec safety window callbacks are not killed, and at termination, the new callback will contain the more recent buffers. Then the callback flags will tell you if something nasty happened: skipped a writing deadline, skipped an input buffer... That's how i understand it - but a PortAudio developer could be more assertive. So i believe you can be confident on the state of the mutex. But anyway, why to use a mutex inside a real-time thread?? Couldn't this be done with lock-free techniques? Regards, Pau ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
