[linux-audio-dev] LV2 buffersize extensions (was: LADSPA...)

Dave Robillard drobilla at connect.carleton.ca
Mon Jan 29 23:25:33 UTC 2007


On Mon, 2007-01-29 at 17:22 +0000, Steve Harris wrote:
> On 29 Jan 2007, at 16:51, Florian Schmidt wrote:
> 
> > On Monday 29 January 2007 09:08, Steve Harris wrote:
> >
> >> Ah, well the host is not supposed to change port values during run()
> >> anyway, the idea in LADSPA (and LV2) is that the host should chop the
> >> run() block where port values change. In practice not all hosts do
> >> that, some just pick a suitably small block size, eg. 32 frames and
> >> quantise the changes to that rate.
> >
> > Hi, let me chime in because it kidna fits into the subject.
> >
> > I have defined two (very very simple LV2 extensions):
> >
> > "The extension’s URI is
> > http://tapas.affenbande.org/lv2/ext/fixed-buffersize
> >
> > All that a plugin needs to check is whether a host feature with  
> > this URI
> > exists and the data will be a uint32 containing the buffersize.
> >
> > The host is only allowed to call the plugin’s run function with a  
> > buffersize
> > equal to the one specified by the host feature.
> > There’s a second extension:
> >
> > http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize
> >
> > which is identical to above but with the additional requirement  
> > that the fixed
> > buffersize has to be a power of two."
> 
> Great idea. I've got some plugins that will benefit a lot by this. We  
> should link to known extensions on the http://lv2plug.in/ site.
> 
> FWIW, my provisional plan was to wait until it seemed like time for a  
> LV2 1.1 (hopefully not too soon :), then roll all the "popular"  
> extensions into that.
> It doesn't make a huge amount of difference whether their included or  
> not though.
> 
> Before you ask, no I don't have a definition for "popular".

I think it might be a better idea to reserve some URI prefix
(http://lv2plug/extensions ?) for "popular" extensions and keep the spec
itself simple, just for the sake of having a simple understandable core
spec regardless of how the more fancy things evolve.

Thoughts?

-DR-





More information about the Linux-audio-dev mailing list