[LV2] How to handle sample rate changes?

[Stefan Westerfeld]

   Hi!

On Tue, Oct 04, 2016 at 09:24:34AM +0300, Vladimir Sadovnikov wrote:
> 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).

Ok. Re-instantiating the plugin is not a great solution, but it sounds like an
acceptable solution. First of all it will guarantee that every plugin will
indeed work with the new rate (unlike the LV2 Options Interface solution).

The problem is: if you for instance have the ZynAddSubFX LV2 plugin UI open
with four windows on your screen, and then re-instantiate the LV2 plugin and
the UI four windows will disappear and a single new window will open somewhere
else.  Strange.

But lucky for us, the sample rate doesn't really change every time. Indeed its
a very rare event, I suppose, and if you're using JACK and BEAST is using JACK
then it even will never happen unless you restart JACK. So if we re-instantiate
only if the sample rate actually changed, things should mostly be fine.

> I also should ask: what benefits delivers such behaviour? Currently I only consider
> that this is a big lack of design of the host.

You could hotplug audio devices, or start or stop JACK or Pulseaudio without
needing to restart BEAST.

Anyway, as for changing the design: maybe future versions of BEAST will allow
you to keep the audio device open even if the project is not playing,
effectively eliminating the "stopped" mode. But as global design changes
generally can be difficult, I don't want to wait for that. And as far as I can
see, even future versions of BEAST shall support changing the audio device on
the fly. So sample rate changes needs to be dealt with in any case.

And yes, keeping the audio device open is also better for custom UIs.

> >>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
> >>it?
> >Theoretically yes, though this would require dedicated support by every
> >plugin.
> Right.
> >
> >>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
> >>requests?
> >http://lv2plug.in/doc/html/group__lv2core.html#a8dbb1fd9ebae0477a11dfc4f0a685d72
> >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 (theoretically)
> can be called at any time. But I think that many plugins do not
> expect that it may change
> after instantiation. So you may hear clicking and popping sounds on
> their output because
> in most cases they are stateful and do not expect spontaneous change of sample rate.

Right. VST does exactly what we need. You can suspend the plugin. Change the
sample rate. Resume processing. Done. The plugin will not have to make these
changes happen realtime, because it is in the suspended state.

However I personally would rather like to support LV2 than VST in BEAST, as LV2
seems to be a truely "open source" way of doing plugins.

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

Well, the point is: all the code needs to be written anyway, because
the plugin must support instantiation with different sampling rates.
So its not about adding extra functionality, but about making already
implemented functionality available to the host.

However, as you say: asking for it now is probably too late.

> >PS. curious: How does BEAST handle automation? in [fractional] seconds
> >instead of samples or musical time?

BEAST always uses musical time for events. The "automation" BEAST currently
supports is more like making a midi part and putting controller events into it.

   Cu... Stefan
-- 
Stefan Westerfeld, http://space.twc.de/~stefan