Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Nov 23 2000 - 17:11:26 EET
>> well, here we come to the crux of things. if MCOP can really be used
>> in applications that seek to offer the same kind of performance as
>> dedicated h/w boxes, then i'm all for learning it and using it. [...]
>>
>> Stefan is probably right that MCOP could be improved/extended to
>> handle such systems. But I suspect there is real work there, work that
>> is not guaranteed to result in a version of MCOP that can still be
>> considered universal in its utility. if stefan really believes that
>> the fixes for this are fairly trivial superficial details, i'm very
>> interested to know more. [...]
>
>Okay, this could get really constructive here. We'll make a test. I will
>give you three of the assumptions that I use, with an estimate how hard
>it would be to undo (fix) them, then you can judge for yourself if it is
>suitable for your purpose.
>
>1. cross server object connection is done blocking
I mostly don't care about this, because in the instances I care about,
such connections would never occur.
I hope i correctly understand the aRts model to include a 1:1 mapping
between a single audio driver API's "audio device" and a server (I
made that complex, since ALSA now provides "multi" support which can
make multiple soundcards appear to be a single device to the
application).
>If MCOP was extended to support threads (no threads currently) by considering
>each thread to a server, the same would apply for cross thread object
>connection.
>
>Fix: thread or state machine for cross server connects eliminates the
>problem. This shouldn't be too hard to implement, though it may be a bit
>of work. Such a change would really fit well into the mainstream MCOP.
This is harder than you think :) I think it is generally easier to use
lock-free data structures in each server that allow any other server
to insert requests in that server's "queue", and simply guarantee that
the request will be processed "soon". Not easy to do this when you
need a response code, however.
>2. audio data = floats
No problem here. I would introduce one other limitation: audio data is
range-limited to -1.0 to +1.0. For 24 bit samples, this can be done
with 32 bit IEEE floats with no loss of resolution in a simple
passthru situation.
>3. mallocs have reasonable costs
>If you only run a fixed set of modules on one server, you don't need malloc.
>All other operations, like connecting modules, sending events, calling
>methods on other servers, connecting new servers,... do mallocs.
the set of operations you describe are things that i simply don't
think should be happening during the execution of the "interrupt
handler" in the RT/SCHED_FIFO audio thread.
let me mention some quite different features that turn out to be very
important in my audio software, and that i would not have guessed at
before i started:
* ability to handle non-interleaved data streams with no performance
penalty
* ability to do per-channel operations with no performance
penalty (more or less equivalent to the first point)
* proper support for pro audio cards (sample clock settings,
hardware monitoring settings, sync source settings,
etc. etc.). These all need to be present in the
abstraction offered to the low-level layers in the
system.
* fragment wakeup count == 1 causes no problems
* moving 9MB/sec of data to/from the audio interface is OK
* use of RTC as a timing source when needed
* 2.5msec - 5msec latency (given a patched kernel)
How does aRts stand with respect to these issues ?
--p
This archive was generated by hypermail 2b28 : Thu Nov 23 2000 - 18:13:50 EET