[LAD] Let's kill EPAMP???

Steve Harris steve at plugin.org.uk
Tue Jun 3 08:30:06 UTC 2008


On 2 Jun 2008, at 19:16, Stefano D'Angelo wrote:
>
>>> #1. Support for interleaved channels and non-float data
>>> Input and output data is often found in these formats.
>>
>> New port type is needed. Keep in mind though, that plugins using this
>> port type will be probably limited to music player hosts. Also if we
>> extrapolate this idea, we will have mp3 stream ports or things like
>> that. Think twice whether it is good idea.
>
> Well, I'd say non-float non-compressed data. I think ALSA's PCM sample
> formats are more than sufficient. If you're worried about third
> parties... LV2 is decentralized by design :-\

I think you'll make everyones life much better if you just provide  
utility functions (eg. in slv2) to convert interleaved integers and  
whatever to channelled floats. Constantly converting back and forth  
between different plugins with different requirements is lossy (in  
audio quality terms) and difficult to get right. Just do it once.  
There's a reason that LADSPA, LV2, VST etc. do everything in floats.

>>> #2. Changing sample rate without re-instantiating all effects.
>>> Gapless playback when chaning songs, for example, should be possible
>>> without performing black magic.
>>
>> While I see nothing wrong to support that in general, if I was  
>> writting
>> a music player, I'd use one sample rate/format do processing using it
>> and convert/decode input streams early in the flow chain.
>
> Me too actually. I don't know.

If you want glitch free playback then you have to stick to one sample  
rate at the card, in which case you may as well do the conversion  
before you start feeding plugins.

Any plugin that uses filters (ie. pretty much anything interesting)  
will have to recalculate it's coefficients and throw away buffers if  
you change the sample rate on it, so you'll be out of luck if you  
expect this to be smooth.

>>> #3. Some serious connection logic thing (all the "equal channels"  
>>> thing etc.).
>>> This needs a thousand flame wars and *deep* thinking.
>>
>> No idea what you mean by this.
>
> If someone is going to write that helper library (or adjust SLV2 or
> whatever), I guess we should find some reasonable conventions to
> organize and use plugins in a chain-like thing. This is damn hard, as
> Paul Davis outlined already on this mailing list, and I actually don't
> know to which degree it should be done.

It's not necessary, just intervene after each run() call, it's not  
hard and on a modern machine the cost is negligible.

>>> #4. Support for time stretching when using non real-time audio  
>>> sources.
>>
>> Why not? AFAIK this has clear uses in "professional" audio world too.

Yeah, but not in "realtime". LV2 could of course support that, with an  
extension, but it doesn't seem like the sort of thing that has enough  
variance that a plugin mechanism is a huge win over using SRC.

>>> #5. Informations about delay time introduced by the algorithm itself
>>> to do syncing with video-sources (for example).
>>
>> Uhm, dont we have such thing in LV2 already? If not, I think we need
>> it. This should be useful for syncing multiple audio streams too. For
>> video sources I'd prefer to have video streams (video port type),
>> probably as event port.

In LADSPA there's a "magic" control out port called "_latency" or  
something, that should apply to LV2 aswell, but I'm not sure if the  
spec says so.

>>> #6. Some way for the host to make sense of the meaning of some
>>> parameters and channels, to better support global settings and  
>>> stuff.
>>
>> No idea what you mean by this. ATM, I miss instantiation stage
>> parameters though.
>
> Example: some LV2 extension tells the host that which parameter is a
> "quality vs. speed" parameter in a plugin. The host can, then, show a
> global "quality vs. speed" parameter to the user.
>
> By "channel sense", I mean the host could know what a channel is in a
> standardized way (I see you have that already in port groups
> extension, it could be generalized to channels rather than ports).

What is a channel that is not a port/port group? Ports can be grouped  
and attributed, as eg. quality v's speed, or you can just say that by  
convention QvS ports have some well-known label, in the same way that  
systemic latency is indicated.

>>> #7. Global explicit initialization/finalization functions for more
>>> exotic platforms (they wouldn't harm, so why not having them).
>>
>> I still dont get what is the use case for this.
>
> Both on the host side and on the plugin side, no need for #ifdefs to
> define initialization/finalization functions and maybe support for
> exotic platforms not having them.

That's just a specification issue, it doesn't require any code. In  
order to use things like the CRT, linkers and loaders invoke global  
constructor attributes and so on, so that's just not an issue.

>>> #8. Rules to find plugins possibly platform-specific and outside of
>>> the specification; possibly one compile-time valid path.
>>
>> AFAIK, this conficts with "LV2 spirit". Why one needs this? If the  
>> goal
>> is to avoid RDF Turtle, this shouldnt be issue with proper helper
>> library for hosts. Still such feature could be implemented in such a
>> helper library.
>
> Nope. I mean there should be platform-specific rules to get the list
> of directories containing shared object files and possibly there
> should be a fixed path to check on each platform, known at compile
> time.

That's all in the specification. You can also do more sophisticated  
searches based on attributes of the plugins (EQs, room correction or  
whatever).

>>> #9. Maybe more strict requirements on both hosts and plugins
>>> (especially about thread-safety).
>>> I see there is some indication in the core spec, but I don't know
>>> about extensions and/or other possible concurrency issues.
>>
>> If things are not documented clearly enough I dont see why they
>> shouldnt.

Extensions can label the concurrency properties of any additional  
stuff in a machine readable way, but I don't think that's relevant, as  
without knowing exactly what a new function does, how/why would you  
call it?

>>> #10. Something (a library possibly) to make use all of this features
>>> easily from the host author's POV.
>>
>> I'd choose one path of two host helper libraries, one for music  
>> player
>> like apps and one for more music creation oriented ones. Not sure  
>> whether
>> SLV2 fits in former case, AFAIK it is only used in later ones.
>
> I could help, let's just see how this discussion turns out.

I don't see why you'd need a different library, but hey, the more the  
merrier.

- Steve



More information about the Linux-audio-dev mailing list