Subject: Re: [linux-audio-dev] One API for everything (first draft)
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun May 20 2001 - 15:25:49 EEST
>> #define SOUNDBOX_PORT_PROPERTY_BUFFER_SHAPE /* interleaved, noninterleav
>ed,
>> complex */
>>
>> if a hardware PCM "component" exports this kind of stuff, we're in no
>> better shape than using ALSA when it comes to abstraction.
>
>If I don't export it, you lose efficiency is this what you want?
Yes. The only thing that might deal with hardware buffer layout is a
plugin that interacts directly with the h/w, and it will hide the
layout behind its own i/o ports. No other plugins ever get to write
directly into the hardware buffer. Remember, I wrote a system which
did that, and after using it for quite some time, I've concluded that
its the wrong design. Even just for quality's sake: doing multiple
conversions from the system-wide sample format down to the h/w format
is a lossy way to mix signals. So, yes, details like "interleaved"
etc. should be completely hidden, and matter only to plugins that
interact with h/w. They'll be using ALSA for that, and they can pay
attention to such details as they see fit.
>Really, but what's the problem to have a property to communicate with
>soundbox that you *want* non interleaved buffers.
As Karl pointed out, we don't want to have to support multiple ways of
writing into buffers. The idea of a buffer associated with an (audio)
i/o port is that its an entirely known quantity: a contiguous array of
floating point data.
Somehow, I sense that you still have not understood why so many of us
want this, and want it in a way that is not just "supported", but
"mandatory".
However, even this format for a buffer is not free of the
"run/run_adding" problem, since in some situations, the buffer is most
efficiently used via assignment, and in others maximum efficiency
requires "+=". Its not a trivial problem to make this a run-time
choice, and in many cases, its almost impossible. If you only
imagine simple LADSPA-like plugins, its a bit easier.
However, since the number of ports on the kind of plugins we're trying
to support may be very large and their interconnections very complex,
there is no simple way to tell the plugin to use the "=" or "+="
method; indeed, there may be no simple way for the plugin to select
these methods internally.
This is still an unsolved problem, as far as i can tell.
--p
This archive was generated by hypermail 2b28 : Sun May 20 2001 - 15:41:08 EEST