Re: [LAD] Specification issues in open systems

On Sat, Sep 27, 2008 at 4:39 PM, Paul Davis <paul@email-addr-hidden> wrote:
> On Sat, 2008-09-27 at 14:04 +0100, yikyak wrote:
>> The following is a cross-post of an exchange that took
>> place on the rosegarden-devel mailing list. I'm posting
>> it here because I think it hints at something fairly
>> serious with the current state of open audio specifications
>> and issues with their implementation.

> I don't have anything particularly useful to add to this discussion, but
> I do want to note that I could trawl back through my archives from the
> vst-plugins list and dig up at least a half dozen examples of similar
> behaviour differences between hosts in that world. Every time, the
> plugin authors have to detect which host they are running under and
> alter their behaviour. Nobody likes it and occasionally a host author
> modifies their software to be more like the rest of the bunch. I don't
> think your issue is with "open audio specifications", its with "API
> specifications in tiny little application niches". Good luck with
> resolving the issue. We'll use it if and when Ardour supports DSSI :)
>
> --p

When the VST spec first came out, there was no such trouble (there
were plenty of other problems ...) as the VST apps were the only ones
that supported it. I'm not talking about a minor issue here; it's to
do with how and whether plugin hosts respect the requests the plugins
make of them. Requesting multiple outputs worked perfectly under
steinberg's stuff, it worked perfectly under Reason, it worked
perfectly under Logic (back before Apple dropped it). I don't have the
VST spec to hand, but there were mechanisms (in the post-2 variants
anyway) for requesting resources and then being told whether you could
have them or not and, if not, how many you could have. Every single
Native Instruments VI used this facility, as did many others.

Furthermore, in the VST spec, there was a very easy way to determine
the host under which you were running. IHostApplication::getName() and
IIHostApplication::getVersion() come to mind, but I may be wrong about
the exact details. There is no equivalent under DSSI (or LV2 as best I
can gather).

As part of the testbed application I'd been building, one of the first
things I implemented was a logger in the gui so I could see what was
going on. This is the output from the plugin bootstrap on Rosegarden:

INTERNAL [27-09-2008 17:04:59.232 BST] : Starting ...
INTERNAL [27-09-2008 17:04:59.241 BST] :
Parsed Host Info:
    DSSI Hostname: yerupaja.yikyak.org
    DSSI Port: 17556
    Basepath: /plugin/dssi/10000/synth/phool_synth
    PluginLibrary: phool_synth.so
    PluginLabel: phool_synth
    PluginInstanceID: "Rosegarden: Synth plugin #1"
    GUI (this) Hostname: yerupaja.yikyak.org
    GUI (this) Hostaddr: 192.168.0.2
INTERNAL [27-09-2008 17:04:59.252 BST] : Starting Listening ...
INTERNAL [27-09-2008 17:04:59.266 BST] : Listener up on GUI Port 35095
INTERNAL [27-09-2008 17:04:59.269 BST] : DSSI host resolved to 192.168.0.2
SENT [27-09-2008 17:04:59.275 BST] :
/plugin/dssi/10000/synth/phool_synth/update
osc.udp://192.168.0.2:35095/plugin/dssi/10000/synth/phool_synth
RECEIVED [27-09-2008 17:04:59.292 BST] : Received /configure Command:
__ROSEGARDEN__:__RESERVED__:ProjectDirectoryKey
/home/chris/rosegarden/
RECEIVED [27-09-2008 17:04:59.293 BST] : Received /program Command: 0 0
RECEIVED [27-09-2008 17:04:59.293 BST] : Received /show Command:

and this the equivalent output from jack-dssi-host:

INTERNAL [27-09-2008 17:00:13.988 BST] : Starting ...
INTERNAL [27-09-2008 17:00:13.998 BST] :
Parsed Host Info:
    DSSI Hostname: yerupaja.yikyak.org
    DSSI Port: 10596
    Basepath: /dssi/phool_synth/phool_synth/chan00
    PluginLibrary: phool_synth.so
    PluginLabel: phool_synth
    PluginInstanceID: "channel 0"
    GUI (this) Hostname: yerupaja.yikyak.org
    GUI (this) Hostaddr: 192.168.0.2
INTERNAL [27-09-2008 17:00:14.009 BST] : Starting Listening ...
INTERNAL [27-09-2008 17:00:14.024 BST] : Listener up on GUI Port 47687
INTERNAL [27-09-2008 17:00:14.027 BST] : DSSI host resolved to 192.168.0.2
RECEIVED [27-09-2008 17:00:14.033 BST] : Received /program Command: 0 0
RECEIVED [27-09-2008 17:00:14.033 BST] : Received /show Command:
SENT [27-09-2008 17:00:14.033 BST] :
/dssi/phool_synth/phool_synth/chan00/update
osc.udp://192.168.0.2:47687/dssi/phool_synth/phool_synth/chan00

Now, granted, you could arguably host-detect Rosegarden from the
plugin's instanceID or from the key->value sent to /configure, but
there's nothing in the spec to guarantee that should be there, and
there's nothing to say it won't change on a whim in future. There's
*nothing* about the jack-dssi-host output, however, that would enable
the client to discern where it was getting its service from. it's
tricky to argue that clients should overcome holes in the spec or a
given implementation if there's nothing in the spec that even
guarantees having an ability to do that in the first place.

I can't see this as being anything other than a specification bug. I
don't think the rosegarden developers have implemented the spec
correctly, necessarily, but the spec gave them ample room to do what
they did. In part, this comes about from hacking an instrument API
onto an effects API, when it's debatable how related they are, but
it's mostly to do with not thinking through the use cases when writing
the specification.

Here's what happens when someone tries to write an audio app for
linux. The following is not a "woe is me" whinge. It's meant to be an
example. The main point will come at the end.

When I decided I wanted to try my hand at writing a certain kind of
audio app under linux, I went through all the options based on the
features I wanted to implement: Jack, ALSA, DSSI etc. I chose DSSI as
it was loosely analogous to VSTIs and could, in theory, save a lot of
work on my part. One of the features that I really wanted was output
groups (why anyone would think a given effect should be applied
equally across an instrument is beyond me, but that's a separate issue
...). Going the DSSI route meant you could use the audio and plugin
facilities of the host to do this. Getting to this stage alone meant
at least a superficial bit of research and experimentation with all
four APIs.

Once I decided to use DSSI, this meant: becoming intimately familiar
with LADSPA, intimately familiar with DSSI, familiarizing myself with
OSC, deciding on whether to use an existing OSC implementation or
write one from scratch, researching the options for the latter,
familiarizing myself with the implementation in question, going
through the same entire process with a GUI toolkit and then knocking
up some test code.

And it's *at this point* that I realize the original idea isn't
feasible as envisioned because one of the main candidate hosts for the
app doesn't behave the way the spec implies (not mandates) it should
behave. Nowhere is this information available (certainly not in
rosegarden's documentation). It's something that would have been
useful to know at the initial decision stage.

Now, here's the point.

I'm an experienced developer with over 12 years of mucking about with
audio and over 15 with C and C++ under my belt. I've got 10 years of
linux experience, I read specs quickly, can develop proof-of-concept
models on-the-fly, can code reasonably fast and was already familiar
with some of the options available at the research stage (osc libs,
gui toolkits and parts of the ALSA interface). The above research and
development took three or four days of reading and hacking in my spare
time and the knockback won't phase me that much; I'll figure out
another way of doing it.

Now: *Imagine what happens to newbies when they go through the above*;
people who've only got a year or three in the game, are interested in
linux audio and have an enthusiasm to contribute. Is it any wonder
that linux audio is in the state it's in (even given a really solid
base layer)?

And then you look at the LV2 spec and realize it contains the same flaw.

Chris Williams
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Sep 28 00:15:01 2008