Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 08 2001 - 04:42:31 EEST
lets start from the bottom, rather than the top:
>> as indicated above, ardour is both a producer (when it supplies data
>> to a channel, such as from a diskstream) and a consumer (when it
>> collects data from a diskstream or a channel). your model suggests
>> that it would be necessary to divide it into two pieces. this is would
>> be a sort of reductio ad absurdum, IMHO.
>
>To divide ardour? Absolutely not: in my mind ardour is a complex engine
>that drive data from a set of producer to a set of consumer.
>
>You seem to not understand that in my model ardour itself it's neither a
>producer nor a consumer: it's an application that act as a bridge
>between producers (diskstream or channels) and consumer (diskstream or
>channels).
ardour does not do this. thats the whole reason why AES exists. the
"bridge", such as it is, is AES, and AES is very different in both
concept and execution than the model i've seen you propose.
ardour is an application with a specific set of internal models:
diskstreams
routes (as in "signal routing")
these are not abstract specifications, but objects designed expressely
to optimize the task ardour seeks to accomplish. they are not plugins,
they cannot be replaced by external components of some sort.
>> LAAGA was proposed by Kai, somewhat based on my AES system. it doesn't
>> meet the description you propose at all.
>> in it, an engine is the core application. it has 3 responsibilities:
>
>same in my model
>
>>
>> 1) "masking" all access to the audio hardware via
>> an abstraction: X channels of capture, Y channels of
>> playback, each channel consists of 32 bit floating point
>> data, no parameters of any kind.
>
>here I disagree, to have parameters may be very useful for negotiate
>audio components communication details
but there are no parameters to negotiate. the engine provides
information about its frame rate, and the number of 32 bit float
channels for capture and playback, possibly with the number of each
"type" of channel (physical, internal bus, etc.; not that there is
anyway of distinguishing them functionally). the plugin has no role to
play in determining any of these.
i don't call this negotiation. perhaps you do. it might explain why
we're having so much difficulty with this conversation :)
>> 2) executing its plugins in a way that guarantees totally
>> synchronous operation.
>
>same in my model
I don't see how this can be. In your model you have an engine that
you've said is not a producer or a consumer. I can therefore see no
reason why it should be interacting with an audio interface at all.
Perhaps its not clear what I mean by totally synchronous. I elaborate
more below...
>> 3) facilitating data sharing amongst its plugins.
>
>This is too generic for me, I don't understand what you mean.
"allowing plugins to write and read their audio data to/from places
where other plugins can also write and read"
>> a key feature of the AES/LAAGA model is that the audio h/w *drives*
>> the engine (this is a requirement for fulfilling (2) above). in your
>> model, it seems that audio h/w capture is controlled by a producer and
>> audio h/w playback is controlled by a consumer; its hard for me to see
>> how this could work. do you designate a particular producer as
>> "special", and somehow have the engine do its thing when that producer
>> says it has data ready? what if that producer is not a h/w producer at
>> all?
>
>for each producer
> producer->wait()
how can producer->wait() work ? things are supposed to be
running in perfect sync, so what is it waiting for? is it the same
thing that every other producer is waiting for ? is it the same thing
that every consumer is waiting for?
the point about "totally synchronous operation" is that its defined by
the audio stream handled by the audio interface. when we say that
we're ready for the "producers" to "get" and the "consumers" to "put",
then to me this implies only one thing: there are "nframes" of
data/space available to move audio data from/to the audio
interface. as soon as you try to split this up into two different
"waits", its very hard to enforce that this condition is being met.
>It's so easy (and it solves the problem you've encountered recently with
>ardour about playback/capture ready condition drift)
I don't think this easy. It requires a dichotomy between producers and
consumers. Producers and consumers are not the basis for audio, even
though in an OOP world view, they might look like it. Instead, there
is data and space available on an audio interface. This is the driving
force, the only driving force, behind any audio program that is based
on the kind of operation that kai has elaborated in some of his
email. The model is this:
while (!done) {
wait_for_nframes_of_capture_and_playback ();
foreach engine plugin {
plugin->process (nframes);
}
}
thats even simpler. its also a proven model.
>> i consider the interleaved mode of operation a historical accident
>> that it would be wise to abandon. its less efficient for
>> high-performance systems, and trivial in terms of cost for standard
>> "consumer" applications that route audio to a couple of channels.
>
>This is a not proved argument. If I think for a plugin that swap L/R
>channel on a stereo stream it's much faster with interleaved format.
yes, its faster, but the gain for such a plugin is a tiny fraction of
the loss suffered by a multichannel HDR system. so you have to make a
choice; i'd rather see a very demanding application saved a large loss
than grant a rather small and trivial application a small gain.
and please note this (and I don't mean this as a pedantic argument):
if you are imagining your proposed API being used by "a plugin that
swaps L/R channels on a stereo stream", then we're already talking
about something totally different for sure.
such functionality has been intended by the developers on this list to
be offered by a LADSPA plugin: small, purely algorithmic DSP
operations. i don't know if you've ever read the email discussions
that led to LADSPA, but i would bet a substantial amount of money that
most developers here do not want to see an alternative proposed to
that unless it has the kinds of properties that the now mythical MAIA
has, or possibly is VST or something equivalent.
>However this is not the point (interleaved vs non-interleaved): I've
>asked why you're interested to access channel separately.
because in a non-interleaved situation, the data for each channel is
computed separately, and if we cannot deliver it to the relevant
channel as soon as its computed, we instead have to buffer it in some
intermediate location (i'm assuming optimized code here, that reuses a
buffer space in order to reduce cache misses; such operation should be
considered normal by the kinds of apps we're interested in).
i consider this wasteful. i believe that an elegant API lets me
deliver the data to each channel once its ready, and then notify that
I'm done with all channels (either implicitly, by return() or
explicitly e.g. snd_pcm_mmap_commit()) . The ALSA PCM API (via mmap)
lets me do this.
>We've discussed this recently about alsa-lib PCM API and I think
>you've verified that there is no need for it and probably this make
>to lose some efficiency.
I don't think I've commented on this at all, but perhaps I'm missing
or forgetting one of my own conclusions?
--p
This archive was generated by hypermail 2b28 : Tue May 08 2001 - 05:10:11 EEST