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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Mar 28 20:15:03 2012
This archive was generated by hypermail 2.1.8 : Wed Mar 28 2012 - 20:15:04 EEST