Re: [LAD] LV2 realtime safe memory pool extension

Nedko Arnaudov wrote:

> The point is that some plugins need *realtime safe* memory allocation. I
> need this functionality for lv2zynadd plugin (like arbitrary voices
> count allocation) and for lv2dynparam plugin library internal operation
> too.

I think it might be useful, to provide a "legal" workaround for "no
malloc and free during audio processing" rule. Also, because memory
services are provided by host, some hosts could "profile" dynamic memory
usage per plugin in a way similar to how Buzz measured CPU usage per
plugin. In Buzz community, end users were "policing" CPU usage and
underflow bugs - and it worked. Some hosts could use the same approach
for runtime allocations.

It would also facilitate sharing memory pools between plugins. On the
other hand, it might sometimes make sense to have separate pools per
plugin, to improve cache locality. Without hard data about performance
impact of shared pools it's hard to decide one way or the other.

But if my opinion counts, please provide a LGPL-ed reference
implementation (based on TLSF or anything else that works :) ) and test
suite as well :) So that host authors can simply use them to avoid bugs
and duplicated effort.

However, I'm new here, so my opinion is probably not very important
(well, some people may know my FSM series of Buzz machines - like
Infector or WahMan, but that was quite long ago).

> This has lead to this proposal. But if
> there are no positive opinions for this extension I'll integrate it into
> lv2dynparam extension.

In my opinion, both are independently useful and don't have much in
common - they shouldn't be merged.

> That reminds me that LV2 may need a way to specify optional features
> that interdepend. I.e. features (extensions) A and B are both optional
> but if A is provided B is required.

I think the standard could introduce some "compliance levels", which are
based on sets of features supported.

Like, for example:

Level 1 host - just plain LV2 is supported
Level 2 host - must support dynparams, MIDI port and realtime safe
allocation features (that's how we can push for implementation of both
dynparams and safe alloc without merging the extensions!)
Level 3 host - like level 2 host, but must use a (hypothetical)
value-to-string and string-to-value conversion services in a plugin
where possible (ie. a plugin may provide a function to create a textual
representation of a float parameter value)
Level 4 host - must support some GUI extension (GTK+ GUI or some other,
not yet defined - like something out-of-process in a fashion similar to
DSSI)

There should as well be some test suite to check if the host's and
plugin's behaviour is valid. This way, we could avoid some problems
early VST2 had - like early NI plugins breaking on variable length
buffers (IIRC), or buggy processAdding/processReplacing implementations.

It "kind of" works in other areas. Adopting this kind of model might aid
end users in determining compatibility between their host and plugins,
and help programmers to prioritize their work.

Any thoughts?

Krzysztof
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 8 16:15:03 2007