Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins

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

Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Nov 23 2000 - 20:21:31 EET


Paul, I mostly agree with you,
I'd like too to use ALSA for querying the soundcard's capabilities
and some other stuff.
But on the other hand the host+plugin model offloads much of the boring
stuff to the host.
eg. setting up the card, chosing between pcm_write/read and the mmap model,
and other stuff.
For example plugins could request a certain datatype
(let's say arour's HDR engine want 24bit integer samples)
Other plugins would prefer to work in the float domain.
Other plugs want to work with 16bit samples.
In this case the host would make more datatypes available for plugins,
than the soundcard is capable of. (by doing conversions).
This is only one example where I see that the ALSA API
(for plugins figuring out what the "system is capable of") is not 100% adequate.

The problem is that "the system" in the case of the virtual studio is not a
couple of soundcards and midi interfaces, but it can provide various additional
services, like virtual mixers, networked nodes and other sutff.

You may say that this might take long time to design and that we prefer
the egg today rather than the chicken tomorrow (at least in italy we have this
saying)).
I agree , but in that case I'm prefering using monolithic apps like ardour
which can act as a host for plugins, rather than developing some quick-n-dirty
virtual studio model which over the long term turns out to have many flaws
that we cannot get rid of (since there already tons of apps relying on this
model).

I cannot make any conclusion if we would need to abstract HW-device
querying in a separate API or if ALSA should be used at least for this part.
(audio I/O would be up to the host, which in turn would use ALSA too).

I think this topic need further research and especially we need to know
what does complex audio apps (like ardour) really need to know/setup.
We already discussed the problem of multiple plugins needing different
samplingrate issue, which does not happen in the
"single application talking to the soundcard directy" model.
Other issues are synchronization like wordclock sources, SMPTE etc ...

I like the VST synth/DSP model which means you can run all your
"apps" (plugins) under the hood of a single host , without the need that
every plugin is forced to the soundcard directly.

What I have in mind is something that overcomes VST's limitations so that
a host can host ANY kind of audio app, not just DSP or synth modules.

Perhaps I have a distorted vision of things, but I see this model the only way
to assure both excellent interoperability , flexiblity and latency.

We cannot rely that much on past experiences in this case.
One thing is for sure, that we will need a single threaded model in order
to get acceptable latencies and synchronization.

For now application developers should simply continue to use their
traditional audio programming approaches, but always keeping in mind the
nonblocking audiothread issue, which will permit it for the app to be converted
into a plugin for the virtual studio host.

Benno.

On Thu, 23 Nov 2000, Paul Barton-Davis wrote:

> two comments:
>
> 1) at some point, you have to *commit*. despite all my criticism
> of some of the bumps in the road of ALSA development, i really
> don't have any problem committing to ALSA. if all you want
> is a simplistic, naive audio API, then OSS will work for you,
> and ALSA will support that. but if you want more, why not
> commit to ALSA ? you can waste a lot of time endlessly
> building meta-API's to handle the theoretical day when
> ALSA is replaced.
>
> 2) in my experience of writing linux audio s/w, the abstractions
> required by a lot of audio apps can be embodied very easily
> in a simple API. ardour's ALSA::MultiChannelDevice is an
> example of one such API - its not perfect or comprehensive,
> but it for low latency mmap-using applications, its pretty
> good. It would not be hard to make a more generic one that
> could satisfy almost all applications. This doesn't mean, BTW,
> that I think that ALSA is overly complex - it contains
> capabilities that a few programs need some of the time,
> and thats great. And in fact, the basic ALSA API "template":
>
> snd_pcm_{open,params,prepare,[read,write....],close}
>
> is also very simple.
>
> A notable exception is when dealing with odd audio formats, and
> facing the whole question of whether to convert them first or
> relying on the h/w or device driver to take care of it. I
> believe that ALSA (alsa-lib) 0.6.0's "plugin" model combined
> with the new 0.6.0 config files can solve this problem very
> easily without creating more application complexity.
>
> >That way the virtual studio API could even run under OSS,
> >(and any other audio API)
>
> As detailed by me the other day, "the virtual studio API" cannot use
> OSS with pro audio cards. Why waste time on this ?
>
> --p


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

This archive was generated by hypermail 2b28 : Thu Nov 23 2000 - 19:57:45 EET