28 Mar
2012
28 Mar
'12
7:55 p.m.
On Wed, 2012-03-28 at 10:47 -0700, Ed Sweeney wrote:
On 03/28/12 10:45, David Robillard wrote:
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
[...]
gotcha, thanks david. looking at ringbuffer now. 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.