On Wed, 2012-03-28 at 10:47 -0700, Ed Sweeney wrote: > On 03/28/12 10:45, David Robillard wrote: > > > [...] > >> Emanuel, thx for the suggestion. The job of that mutex is to block the > >> callback until the user code has run, _trylock wouldn't do that. > > > > "Block the callback" = "Cause a dropout" > > > > Don't do that. > > > > The standard solution if you need to process audio with > > non-realtime-safe code is to ringbuffer the data to/from the process > > callback. > > > gotcha, thanks david. looking at ringbuffer now.
You're welcome. The capture_client.c example in jack is sort of what you'd have to do, but only in one direction. Someone else may know of a more directly applicable example... (Though, personally I'd suggest using a semaphore if available instead of a mutex/cond pair; sem_post is the best way to signal from the audio thread and the signal will always "get through" unlike a trylock. Semaphores are awesome, it's really a shame that most portability libraries (and C++0x) don't include them...) -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
