El dj 24 de 04 del 2008 a les 17:53 -0400, en/na Albert Santoni va escriure: > Hi Bjorn and Pau, > > Thanks for the enlightening responses. After thinking about what you've > both written for a day, I have a few more questions: > > 1) It looks like the watchdog thread attempts to run at higher priority > than the callback thread, so it can do its job. However, when the > callback thread is running with realtime priority, what priority does > the watchdog thread run with? I'm wondering if the watchdog thread can't > do its job if you have a realtime priority callback thread. If that's > true, then if you have a series of callback underruns (ie. they don't > finish in time), more and more callback threads might be created, and > you might unintentionally end up with the equivalent of a fork-bomb. > (Too many threads crashing the kernel... ?)
I believe that multiple callback threads are never created (but take it with a grain of salt since I'm saying that without having looked at the code) The existence of status flags in the callback function that tells you if you missed to read a buffer (and other bad things) makes me think that. If a new thread was created on each driver trigger you'd never miss reading a buffer (that is, the host wouldn't know). Besides, allowing sharing userData between different threads seems a VERY bad idea. On the other hand a sequential ordering of callbacks, even if they miss deadlines, seems reasonable. Could any PortAudio expert confirm this? Cheers! Pau > > 2) Besides Ross Bencina's notes on lock-free and wait-free algorithms > ( http://www.audiomulch.com/~rossb/code/lockfree/ ), are there any good > resources people can recommend on the topic? (Books, websites, etc.) > > 3) In Mixxx, there are two spots where we dump audio from the callback > into a separate worker thread, and in order to notify the worker thread > that there's data that needs processing, we use a QWaitCondtion. The > QWaitCondition requires the use of a QMutex around calls to it, so we > end up locking/unlocking this mutex in the callback thread (bad). Is > using something like PortAudio's ringbuffer an appropriate solution for > eliminating the mutex/wait condition in this situation? > > Thanks again, > Albert > > > On Thu, 2008-04-24 at 09:28 -0400, Bjorn Roche wrote: > > Albert, > > > > I'm not sure I understand exactly what you're wanting to know, and > > I'm no longer an expert on the watchdog thread since I don't work on > > the platforms that use it anymore, so you'll have to take what I say > > with a grain of salt. The watchdog thread, IIRC, only kills the > > callback thread if the callback is overrunning the CPU, and seriously > > blocking lower priority threads from getting anything done at all for > > a significant period of time, as detected by the so-called "canary" > > thread. This is not the standard buffer underrun scenario. It's really > > a disaster-prevention scenario, eg if your callback gets stuck in a > > loop, making the computer completely unresponsive. The only time I've > > seen it kill my thread is when I've made a programming error resulting > > in a total system freeze up for three (?) seconds (including mouse > > movements), in which case it's a real godsend. It may not be necessary > > in the future, because of design improvements in Linux, which will > > hopefully be picked up by other OSes: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/scheduler/sched-rt-group.txt;h=1c6332f4543c350889eae9ba2b4c766270c1b65e;hb=HEAD#l38 > > > > As for what happens when an underrun occurs, it's possible that a new > > thread is launched on some platforms and the old one is killed, I > > don't know. This doesn't happen on Linux (OSS, ALSA or JACK) AFAIK, > > but I could be wrong. It's possible that this does happens on the mac > > OS -- I wrote the code and couldn't tell you because, AFAIK, it > > doesn't say in the Core Audio docs -- but creating a new thread is > > expensive and unbounded and I don't know why they would do it when > > they are already falling behind. Older platforms don't even use > > "threads", they use interrupts, so you should not expect each callback > > to occur on the same thread unless you know something about your > > platform. I imagine other techniques are possible as well, so I > > suspect newer OSes may not use threads either, but I am having a hard > > time imagining what that would be (still, I wouldn't rule it out > > unless an OS expert knows better). It seems to me that it's possible > > that on such platforms, you could have multiple simultaneous callbacks > > during an underrun condition, at least in theory, but I think I would > > consider such a platform broken. > > > > That said, it is widely known to be bad multithreaded programming to > > kill a thread at random (unless a seeming disaster has occurred, like > > a thread has caused your machine to deadlock, in which case you should > > probably exit right away because something really bad just happened) > > rather than wait for the thread to complete, so if an implementation > > was not waiting for your callback to complete for any reason other > > than disaster avoidance I would consider that a bug in the > > implementation. I can't say there are no bugs in any of the > > implementations, but my assumption has always been that callbacks will > > complete, because if they didn't I would file a bug report. > > > > I assume you are aware of the issues relating to using mutexes in a > > realtime thread. > > > > I hope that answers your question. > > > > bjorn > > > > > > On Apr 24, 2008, at 4:50 AM, Pau Arumí Albó wrote: > > > > > > (This mail was already sent to mixxx-devel. I realized that portaudio > > > was also at the Cc when received an "subscribers-only" bounce. > > > So now resending it now after subscription) > > > > > > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > Portaudio mailing list > > > [EMAIL PROTECTED] > > > http://techweb.rfa.org/mailman/listinfo/portaudio > > > > ----------------------------- > > Bjorn Roche > > XO Wave > > Digital Audio Production and Post-Production Software > > http://www.xowave.com > > http://blog.bjornroche.com > > http://myspace.com/xowave > > > > > ------------------------------------------------------------------------- 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
