17 Jun
2004
17 Jun
'04
2:17 p.m.
Pete Bessman <ninjadroid(a)gazuga.net> writes:
At Thu, 17 Jun 2004 12:50:06 +0200,
Mario Lang wrote:
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
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.