Re: [linux-audio-dev] One API for everything (first draft)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] One API for everything (first draft)
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun May 20 2001 - 16:33:29 EEST


>You're a professional audio bigot ;-) soundboxes are also for hundreds
>of application that have always used interleaved buffers.
>
>Do you want *really* to have two APIs, one for professional level and
>one for consumer one?

If its possible, I'd like a single API that works for both. Thats why
I want non-interleaved buffers, since it works for both. We've hashed
this out before: the cost to stereo apps of using noninterleaved is
not zero, but its small. the cost to heavily multichannel apps of
using interleaved buffers is large. ergo, the buffer format should be
noninterleaved.

I hear you say "why restrict it? why not allow either?". Because as
Karl and I have both said, standardizing on the buffer format is
efficient, it makes coding simpler, it works.

>> This is still an unsolved problem, as far as i can tell.
>
>In my model the choice is left to soundbox client/user and it's not
>*dynamic* (it's a property and not a control). Only relaxing the
>soundbox it's modifiable.

Abramo, I'm not sure we're even on the same planet on this issue.

My mindset starts with something somewhat like LADSPA or VST, in which
a plugin has a series of (audio) input and output ports. These ports
can be connected to other ports (with polarity requirements, of
course; you can't connect two inputs together). Associated with a port
is the address of a buffer where audio data may be read/written. This
address is valid only for the duration of the equivalent of LADSPA's
"run/run_adding" callback, and VST's "process/process_replacing"
callback, executed by the engine on the plugin (i.e. it may change
from callback to callback).

If we connect an output port to two input ports, then the input ports
can use the same buffer address as the output port. The plugin with
the output port can use simple assignment to write data to the
buffer. The plugin(s) with the input ports just read data from the
buffer. No problem.

But if we connect, for example, two output ports to a single input
port, then either:

      1) the output ports have to have their own buffer, and some
          "invisible hand" mixes them together and stores the result
          in the input port buffer,
OR

      2) or the plugin(s) with the output ports have to use
            "+=" when writing data to the buffer.

So, the method used to send data to an output port is a function of
what its connected to, and not a property of the port.

Either that, or you prohibit multi-input ports. That might be OK to
do, but it prevents a simple and efficient implementation of the "bus"
concept, which seems like a significant loss.

Thats how I see it, at least.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun May 20 2001 - 16:50:54 EEST