[linux-audio-dev] Multithreaded programming for a poll model?

Mario Lang mlang at delysid.org
Thu Jun 17 18:08:36 UTC 2004


Pete Bessman <ninjadroid at gazuga.net> writes:

> At Thu, 17 Jun 2004 12:50:06 +0200,
> Mario Lang wrote:
>> I've looked at the lock-free ringbuffer of JACK, but I am not
>> sure if this is really what I need here.  
>
> The lock-free ringbuffer is necessary to communicate to the audio
> thread in an RT-safe manner.  RT doesn't really mean "goes fast" so
> much as it means "has a guaranteed minimum speed."  If you communicate
> with the JACK thread just by mutex-protected global variables, that
> guarantee becomes difficult to make.  This is because the JACK thread
> will have to lock each mutex to check the value, and there is a
> possibility that it might end up waiting an indeterminate amount of
> time to get that lock if your UI thread has it.  If you use multiple
> variables protected this way, things get worse.
>
> So basically, if you need to tell your JACK thread something, you need
> to do it with a ringbuffer.
>
> What I'd recommend doing is creating a UI thread and having it
> communicate to the audio thread via the ringbuffer.  The audio thread
> would have some setting indicating a chunk of memory or file
> (whatever) to read sound data from, in addition to settings on how to
> read it and where it currently is within the file.  You would adjust
> these settings by checking for messages from the UI in the ringbuffer
> at the beginning of each callback invocation.

I guess what I don't understand is where to do the reading/decoding.
I can't do it in the audio thread since read(2) might block,
and, especially since one of the libraries I use for decoding is
callback driven.   I'm working with potentially very long sound files,
so I can't pre-decode them all into memory in advance either. I think for this
to work, I'd need some prebuffering in between, and the audio thread somehow
singaling to the decoder thread when the buffer is too empty to safely
continue sleeping so that the decoder can start to fill more data
into the buffer.

-- 
CYa,
  Mario



More information about the Linux-audio-dev mailing list