On Sat, Sep 22, 2018 at 9:17 PM Arun Raghavan <arun at arunraghavan.net> wrote: > > > On Sat, 22 Sep 2018, at 10:03 PM, wellington wallace wrote: > > Hi PA developers! > > > > As you can see here https://github.com/wwmm/pulseeffects/issues/288 > there > > are users that would like to have avoid-resampling supported in > > PulseEffects(and I would like it too). But honestly I am out of good > ideas > > about how to do this. At this moment I am using null sinks to do the > audio > > routing and there is a Gstreamer pipeline that records from it. I can > > change the format and rate of the GStreamer pipiline to the ones used by > > the audio application being processed but as I can't do the same to the > > null sink it would be pointless. The resampling would happen anyway. > > > > At this moment the only way I see to support avoid-resampling would be to > > reload the null sink with the new rate and format. But this is really > > annoying because as soon as I kill the null sink Pulseaudio will move the > > audio application back to the default device. It is not impossible to > deal > > with this. But it may require major changes in the code. > > > > Is reloading the null sink the only way to deal with this? It crossed my > > mind to try to make a custom null sink that could change these parameters > > on the fly. But besides the fact that Arch Linux packages do not have > > Pulseaudio developement headers I don't even know if it is possible to > make > > any null sink that would accept this. > > I have patches in the queue to enable reconfiguration for > module-null-sink. > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/14 > > Should be easy enough to add a modarg like we have for ALSA to make it > also just request support at module load time. > > -- Arun > Hi Arun! These are very good news! So is the null sink going to automatically update its rate like it happens with the sound card sink when avoid-resampling is enabled? Or will it be necessary to take action using the libpulse api? Based on what I could understand of alsa-sink code it seems the first option. Assuming this to be the case is the sampling rate update going to trigger the "sink changed" event? An automatic reconfiguration would welcome. This way I can focus only on the GStreamer pipeline and I wouldn't have different code paths for different Pulseaudio versions. Best regards, Wellington -- Prof.° Wellington Wallace Miguel Melo CEFET/RJ Uned Nova Iguaçu -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180922/125fd6c9/attachment.html>
