Thank you George,
Makes sense. I think I can live with this behavior.
Regards
/R
From: Georg Chini <georg@xxxxxxxx>
Sent: Thursday, 28 May 2020 09:03
To: General PulseAudio Discussion <pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx>; Robert Bielik <Robert.Bielik@xxxxxxxxx>
Subject: Re: [pulseaudio-discuss] LADSPA plugin strange behavior
On 27.05.20 12:12, Robert Bielik wrote:
Oh, forgot to mention, I’m running pulseaudio 12.2 on a Raspberry Pi Model 3.
Hi all,
New to the list. I’m setting up a system where I have a post-processing LADSPA plugin. I’ve setup /etc/pulse/default.pa to load my LADSPA plugin and to set it as the default sink.
Running pulseaudio with “pulseaudio 2>&1” I can see all the logs from my plugin, with it being properly initialized upon start of pulseaudio server, and deinitialized when shutting down the server.
But, there is a strange behavior. Running one audio stream with aplay f.i., and then starting another one with paplay f.i., I can see that the pulseaudio server deactivates, and re-activates the plugin. This it does for
any stream started AND stopped.
Isn’t the stream to the plugin supposed to be continuous? Can the pulseaudio server be configured not to do this ?
Regards
/Robert
This behavior is caused by rewinding. Basically, rewinding is used to ensure that
a new stream is heard immediately. Consider a stream running with a large
latency of let's say 500 ms. This means, that PA has already processed 500 ms
more audio than has been played. When a new stream is added, it would normally
take half a second before the new stream is audible. To avoid this, PA will roll back
the latency of the old stream as far as possible and then add the new stream.
For a filter this means, that it has to process audio that already passed through
the filter. This can lead to distortions. In an ideal case, the filter would be able
to rewind to the state which matches the point in time where the stream is picked
up again. This is however not possible, so PA resets the filter in the hope that this
has less impact than simply running the same audio through the filter again.
For me, the concept of rewinding was difficult to understand, so I hope the explanation
is understandable. The correct solution here is to avoid rewinding completely for
the LADSPA sink and limit the latency to some small value. I have patches that do
exactly that, but they depend on lots of other patches that are still not reviewed.
For the moment I guess you have to live with that behavior (or you could patch the
LADSPA sink not to reset the filter and see if this gives better results).
The information in this email (including any attachments) may contain confidential and/or proprietary material. Any review, retransmission or use of this information by persons or entities other than the intended, authorized recipient is prohibited. If you
received this email in error, please notify the sender and delete the material. For information regarding how Dirac handles personal data, please visit https://www.dirac.com/privacy-policy.
