Lars Luthman wrote:
>> Yes. But that makes it impossible to use a fixed size buffer. If we
>> already have a fixed size buffer extension, why break it this way?
> I just don't like to add complexity to the port buffer struct. Sure,
> worrying about one extra pointer may seem silly, but it's yet another
> thing that the plugin needs to check. The simpler the better.
It's not just extra pointer, it's also extra outer loop in every plugin,
so the complexity is definitely there.
> A host doesn't necessarily have to allocate one fixed-size memory block
> for every plugin event port, it can use one large shared buffer and dole
> out portions of it to each input port in each period,
What about plugin-to-host communication, then? Before getting the events
from the host we set the capacity to maximum, and after the plugin
returns, we just reuse the part that wasn't used by the plugin for other
events?
>> Why not use lv2:optionalFeature?
> Because it isn't really a separate optional feature, it depends on
> whether 1) all event ports have the lv2:connectionOptional hint and 2)
> the host doesn't plan to connect to any of those ports.
Are hosts forced to reveal all features that they implement for
instantiate call, or just the ones mentioned by the particular plugin in
RDF?
In theory, passing some features to a plugin despite if they use the
features or not, might require the host to create additional objects,
often unnecessarily. That's not a huge problem though.
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 29 16:15:06 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 29 2007 - 16:15:07 EET