Subject: Re: [linux-audio-dev] realtime audio i/o with disk input
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Mar 20 2002 - 17:45:04 EET
>Okay, I'll make that max-1
>> you don't need to use mutexes for the buffer itself. when there is one
>> reader and one writer, you can use a lock free ringbuffer. this will
>> avoid blocking the audio thread when it goes to see if there is enough
>> data.
>
>Okay. Anyway, things are Wrong when there is not enough data.
yes, but if you have to sleep on the mutex because the butler thread
has it right then, you've just lost tens of usecs at least.
>Okay, so I understand that you use the audio thread check if the
>buffer needs to be filled, the opposite of my approach, where the
>disk in thread checks this. Any particular reason for this?
yes, there is - consistency. there are two times when we need to call
the butler thread:
1) when we've used enough data from "our side" of the buffer,
and thus the butler needs to handle "its side"
2) when we invalidate the buffer contents because of a transport
event (like a locate), and need the butler to refill.
so, i have a single call, "summon_butler()" that is used to handle
either case. in (2) its preceeded by
wait_for_butler(); // waits until the butler thread is inactive
invalidate_buffers(); // set buffer pointers so that the butler
will refill it entirely next time
there are several times when i need to stop the butler thread from
being active - if its ran periodically all by itself, i have to use a
more extensive and more long-lived locks to prevent it from
interfering with certain transport related activities. that wouldn't
be a *bad* approach, but the one i use has evolved to the point where
it seems to work really well.
the other issue with the butler thread is to make sure that it *never*
does disk I/O in small chunks, and that it will keep working on those
buffers that need more data but *always* in a round-robin
fashion. that is, if buffers A and C need 2 chunks of data, and B
needs 3, you load each one with one chunk, then do that again, then do
B alone for its third chunk. this allows the butler to handle
varispeed tracks with ease, without starving out tracks running at
normal speed while you do "too much" work on those running ahead.
all disk i/o in ardour happens in chunks of a fixed size, never more,
never less. the default size (based on empirical studies on the
relative throughput improvement as read sizes increase) is 256kB.
>Ah, okay, in my approach the disk-in thread enters a while to see
>if the readindex has moved enough. It checks all the time, even if
>the readindex did move but not enough. With your approach, you only
>signal when you _know_ it has moved enough. Is that it?
more or less.
>What is the wake-up mechanism you use? pthread_cond_signal/wait?
yes.
sorry that i don't have more suggestions on why your IDE drives or X is
messing you up.
--p
This archive was generated by hypermail 2b28 : Wed Mar 20 2002 - 17:33:57 EET