[LV2] How to handle sample rate changes?
sadko4u at gmail.com
Mon Oct 3 23:24:34 PDT 2016
04.10.2016 01:20, Robin Gareus пишет:
> On 10/03/2016 10:47 PM, Stefan Westerfeld wrote:
>> I'm considering adding LV2 Instrument support to BEAST. Unlike qtractor or
>> Ardour, BEAST doesn't have a concept of project|session sample rate. It is
>> renegotiated every time the user presses play, and thus subject to change. Now
>> the standard LV2 API doesn't allow me to change the sample rate at runtime, as
>> it is set during initialization.
> If the SR is negotiated when you press "play", there's already some
> overhead and it's not realtime. I suggest to simply re-instantiate the
> plugin while you're at it.
> The downside is that custom GUIs will also need to be re-instantiated,
> then again those won't respond anyway if the plugin itself is not
> running (during your host's "stopped" mode).
I also should ask: what benefits delivers such behaviour? Currently I only consider
that this is a big lack of design of the host.
>> After some research I found the LV2 Options Interface, and the possibilty to
>> dynamically supply the plugin with a new sample rate. So is this the way to do
> Theoretically yes, though this would require dedicated support by every
>> I suspect that many plugins will assume that the sample rate is constant,
>> because the standard LV2 API suggests it. Should we in this case file feature
> says explicitly that the sample-rate is per instance. It's not a
> "suggests", is it?
> All major plugin-standards (VST, AU, ..., LV2) expect a fixed
> sample-rate which is given at instantiation time (the plugin can
> allocate buffers, pre-calculate time-constants, setup filter-banks,
> convert samples,... etc). For most DSP, changing the SR is not realtime
> safe and requires re-initialization.
About VST it's not all true. VST has it's own callback effSetSampleRate that
can be called at any time. But I think that many plugins do not expect that it
after instantiation. So you may hear clicking and popping sounds on their output
in most cases they are stateful and do not expect spontaneous change of sample rate.
> While you could file a feature request for an extension-interface to
> inform plugins about SR changes, I doubt may plugin authors will
> implement it.
> Ports that have the property http://lv2plug.in/ns/lv2core/#sampleRate
> will need to be re-set and plugin-latency may change.
> In case of an EQ with GUI for example, not only the filters will need to
> be re-calculated but also the GUI-Grid, transfer function display and
> possible FFT (EQ with spectrum-display) will have to be updated
> dynamically. Convolvers would need to resample the IR, Synths
> re-generate the wavetables, Reverbs reset the delaylines,...
> Frankly, it's a can of worms.
That's right, a lot of tasks to do when the sample rate changes.
> PS. curious: How does BEAST handle automation? in [fractional] seconds
> instead of samples or musical time?
> Devel mailing list
> Devel at lists.lv2plug.in
More information about the Devel