Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu May 10 2001 - 07:52:04 EEST
>Hmmm . . . . this doesn't really answer the question. There is no basis
>for the sorting that I can see. Example: App1 requests to read and write
>to channel 1 and App2 requests to read and write to channel 1. This is
>not a feedback loop, but I can see no way to determine the order of the
>reads and writes. Excuse me if I am missing something obvious, but what
>is the simple sorting algorithm that can determine this?
If channel 1 is a physical channel, then no data sharing is
possible. Just as in a physical mixer, data sent to an output is not
available for bussing; if you want to share the data, it needs to be
written to a channel that maps to an internal bus.
With this in mind, if application 1 is writing and reading to a
channel that maps to an internal bus, then either the user is stupid
or more hopefully, there are entities within the application that are
sharing data between themselves via the bus.
If application 2 is also using that bus in the same way, then its
going to mix its data into the bus.
Since both apps would have been doing it because they were sharing
data *internally*, this configuration is a mistake on the user's part,
since it mixes the data from two apps into the same bus when they both
were trying to use the bus for their own purposes.
A more useful example is application 1 writes to bus channel 1 and
application 2 reads from bus channel 1. We know that app 1 must run
before app 2. if app 1 also reads from bus channel 2 and app 2 writes
there, then we have a feedback loop at the application level, and its
not solvable in a general way: any execution order will have
problems.
>The point of this is that there is no reason to present data to the
>plugins that they cannot use - if there is no operational difference
>between channels and buses the plugins shouldn't care. The result of
>removing it is that servers are given more flexibility for their
>implementation.
There *is* an functional difference between types of channels, just no
difference in the API to use them. Just as in an engine that
offered network channels (which AES may well do soon): these are
functionally different from channels associated with an audio
interface, but you use them in exactly the same way.
>> LADSPA doesn't work unless you require that the plugins write to some
>> intermediate buffer (they only have audio "ports" that they access as
>> regular memory). This might be OK for a LADSPA plugin - for
>> multichannel apps, you're forcing data copying on a large scale, which
>> is rather pointless and very inefficient.
>>
>
>Well, this is the case with the run method but not the run_adding method.
>I was forgetting that the default is run insead of run_adding. As far as
>the buffering goes it is really just a simple directed graph sorting
>problem - when there is no need for the extra buffering it could just go
>away.
I'm not talking about that kind of buffering. In the LAAGA model, its
possible (given a server implementation) to have data moving from the
plugin's local buffers directly into the h/w DMA buffer. But you
cannot give the plugins access the DMA buffer of the hardware to write
using store instructions. They don't know anything about the physical
format of that memory in terms of sample format, interleaving
etc. This is completely hidden inside
{read_from,write_to}_channel(). So you have to inevitably add at least
one extra layer of buffering quite apart from the "crude" solution to
run/run_adding that would add another.
When there is buffering you are left with a) more memory needed -
>this is really not that large of a requirement and b) potentially more
>L1/L2 cache misses - and I have not seen hard numbers that this would be a
>big performance hit.
Indeed, it might be OK. I'll probably try it with AES soon. Thats one
of the benefits of having a real, working model for all this :)
[ LAAGA and LADSPA ]
>I would argue that these distinctions are present more in the discussion
>and documentation than the apis. They are both about presenting a _very_
>limited api for the exchange of audio data.
Totally agreed.
The only real differences, in
>my mind, are 1) the run thing and 2) control data. And as far as control
>data goes, it seems like including that would allow the sharing of midi
>like data between apps . . .
Except it would be MIDI data as floats :) yikes.
>> However, my feelings on this are evolving. There might some good
>> reasons to force the AES engine to use intermediate buffers, in which
>> case {read_to,write_from}_channel would be redundant, and we could use
>> the LADSPA audio port concept, and have the plugin just scribble on
>> memory. OTOH, this brings up the run/run_adding dichotomy that I
>> worked so hard to get away from ...
>>
>
>Well, I really like not having to care about the run/run_adding thing.
>In my own software I write C++ classes that operate on single samples
>(tick() in STK terms) and then make run and run_adding methods from that.
>With function inlining everything is fast. I also use iterators to
this is never going to work in the multichannel case Karl. right now,
in ardour, a 1.3ms period at 48kHz takes about 0.8msec to compute with
24 active channels of disk-based data and no plugins. I think I can
reduce that (its without any optimization for a start), but a lot of
that overhead comes from function call chains that will never be
inlineable. To execute those same call chains one sample at a time
across 24+ channels will be impossible on today's processors.
>Anyway, I think it is worth thinking about just using LADSPA for this.
>As Abramo says - one api is better than many :)
I agree with the first thought, but not the second :)
--p
This archive was generated by hypermail 2b28 : Thu May 10 2001 - 08:20:25 EEST