сб, 20 апр. 2019 г. в 15:20, Georg Chini <georg@xxxxxxxx>: > > On 20.04.19 12:14, Alexander E. Patrakov wrote: > > [forgot to CC the list - sorry for any duplicates] > > > > сб, 20 апр. 2019 г. в 14:39, Georg Chini <georg@xxxxxxxx>: > > > >> I think using malloc() when a parameter changes is not interfering > >> with real-time operation because the filter must be reset after > >> a parameter change anyway. > > The parameter changes allowed during the runtime are not expected to > > need a filter reset. In-place rebuild - yes, reset - no. The filtered > > audio should smoothly follow gradual changes of the filter parameters. > > Many LADSPA plugins actually implement internal smoothing of parameter > > value changes, or even internally keep two filter versions and > > interpolate between them, in order to avoid clicks, because such > > gradual changes are an expected thing in pro audio workflows. > > > Within PA, the filter must at least be rewound when a parameter changes. > Because rewinding is not part of the standard, the best we can do is to > reset the filter in that case by calling deactivate() and activate(). This is a bug in PA. Non-rewindable sinks are supported, actually exist (e.g. alsa-sink when the ALSA device is an ioplug, e.g. an AC3 encoder) and make sense if the latency is artificially limited to, say, 20-50 ms. So a LADSPA sink must just say "I can rewind zero samples", limit the latency, and ignore all rewind requests. -- Alexander E. Patrakov _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
