Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Sun Dec 16 2001 - 01:38:58 EET
On Sat, 15 Dec 2001, Paul Davis wrote:
>>Or is it? I think the read/write interface suits well for implementing
>>wait()-then-operate(). With a blocking read() application says, "wait
> well, there are 2 problems.
[...]
> 1) it actually means that they work in the wrong order:
> generate data
> wait until there is space (i.e. next h/w interrupt)
> copy data from my buffer area
Hmm, you are right. On the other hand for lowlatency operation it is good
that you have the data ready, but true, you are always slightly
behind/ahead.
> conceptually wrong - their code is being driven by the work their
> program has done rather than the work that the graph needs
> them to do. maybe this is nitpicking, but it seems like an
And my code. :) I'm now working on a JACK plugin for ecasound, and
battling with _just_ this issue.
> i have a feeling that this is important. its important because
> it means that there is no guarantee that the program will have
> data ready when it is supposed to. even if it could meet the RT
> timelines, it may be doing something else when the interrupt
> comes in. it could still get its data delivered in time
> to meet the h/w constraint, but not to satisfy the graph.
... very true. But this can also make life difficult for some of us. For
instance with ecasound it seems I have three options on how to implement
JACK support:
1) integrate JACK-support tightly to the engine, so I could run
whole ecasound engine loop from the JACK client callback
context
2) implement a small JACK-framework inside ecasound -> basicly
I'd have to add a new plugin type similar to JACK's driver
type, which would be responsible for running the engine
3) keep the ecasound engine and JACK callback contexts
separate and use pthread signal+cond to synchronize
callback and engine control flows
(3) is the easiest, (1) the messiest while (2) is probably the best. Guess
which one I just implemented? Yup, always the easiest. :)
Now the interesting thing is that most other app developers will face the
same alternatives. Will others be as lazy as I am...?
> 2) the second problem is that the read/write interface doesn't
> restrict people to working in chunks of audio that match the
> period/cycle/avail_min numbers. this then leads to them both having
> worse latency, with all that implies.
This is also true.
> Neither of these designs is appropriate as far as i can see for a
> synchronous execution system. This points to the final problem with
> the read/write API: it encourages mono-threading. this works for a
> number of simple programs, but in an low latency RT graph, it will
> almost invariably break.
And, unfortunately, also raises the difficulty level quite a bit. My
experience has been that although most programmers can write multithreaded
code (and always want to), very small percentage can actually make it
work. For the rest, their code almost works, but random segfaults and
halts just never go away complitely. And if you picture thousands and
thousands lines of this kind of code, and yup, you've just entered the
wonderful world of large-scale commercial sw-engineering... Your task:
there's a few "minor" bugs you need to fix. Aarggh!!! ;)
But of course, this is a not really a limitation, just something that is
absolutely needed in audio programming. And yes, it's good that the API
makes the requirements explicit.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Sun Dec 16 2001 - 01:37:24 EET