Re: [LAD] LV2 realtime safe memory pool extension

Krzysztof Foltman <wdev@email-addr-hidden> writes:

> 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.

Exactly, it is host business to devide and apply such policies.

> 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.

Well, I write GPLed code (not LGPL) but I may use LGPL library in
Zynjacku. I don't see much duplication effort on integrating same
existing memory allocator in different hosts. If it is suitable :S

> 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).

I personally count ppl opinions based on what they say, not how "new"
are they. :)

>> 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.

Cool :)

>> 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)

I dont think such leveling can be defined. For example custom and generic
GUIs are at same level. Maybe there could be feature (extension)
sets. They may need to be defined in ttl file too.

> 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.

Unfortunately, I doubt test suite will happen at all. I think it will be
more like, plugin A version "n" is known to work well in host B, vesrion
"m". Also testing imposes kind of certification, i.e. work that IMHO
should be done by packager. see below...

> 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.

I beleive this would would be needed only for plugins/host not packaged
for given Linux distribution (OS). This probably means third-party
commercial software. For binary packages, it is packager reponsibility
to ensure compatibility or document incompatibilities in packages.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev