Subject: [linux-audio-dev] audio-disk thread interaction Was: Re: discussion about development overlap
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Sep 28 2000 - 20:07:11 EEST
On Thu, 28 Sep 2000, Paul Barton-Davis wrote:
(Paul's description about how ardour threads do work, elided .... )
Paul, thanks for the explanation, some more points:
I can confirm that pthread_create IS fast:
150usec on my PII400 (tested with a loop of 100k phtread_create).
I do not know what's the "worst case" time, but it looks good.
To note that the RT plugin model I have in mind,
basically allows the clients (the apps) to specify if they want
their own disk thread or if they want to be a client of the disk client
scheduler.
Why this ?
Assume we are running EVO (which does disk IO) and ardour
at the same time:
We all know meanwhile that the disk is used more efficiently when
using one single thread to issue IO requests, rather than multiple
threads which could cause unnecessary disk seeks because the
kernel's elevator can't predict everything.
(see my old single thread vs multithreaded benchmark posts).
So in theory EVO and ardour could have their own private disk threads,
but if we impose some restrictions, like that for each disk callback,
the app cannot read/write more than X bytes from/to disk,
then we could live with one single disk thread which schedules
the disk callbacks of each apps in sequence, giving a better overall
performance.
The limitation of the transfer size will ensure an adequate
"context switch" frequency among disk callbacks of multiple clients,
ensuring that every callback is scheduled regularly, without big
stalls.
This is needed to keep the buffersizes of diskthreads reasonably
low without risking a dropout.
So in Ardour's case , to be rtsoundserver-compliant,
the thread creation would need to be replaced with a message
sent via lock-free structure to the disk "client" so that he knows
what operations to perform.
But this is a trivial change IMHO.
Of course if an app wants his own disk thread at any cost,
we will not prohibit this, but I think the single thread solution can
improve efficiency quite a bit.
Paul, does the proposed model sound reasonable ?
PS: I think this RT plugin model docs needs to cover the GUI part
too (how to decouple GUI commands from the audio thread , atomicity etc),
or application developers will reinvent the wheel over and over again.
Benno.
This archive was generated by hypermail 2b28 : Thu Sep 28 2000 - 19:56:27 EEST