[pulseaudio-discuss] Suggestions on how to support avoid-resampling on PulseEffects

[wellington wallace]

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.

Any suggestion would be welcome.

Best regards,
Wellington

[Arun Raghavan]

Post by wellington wallace
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

[wellington wallace]

Post by Arun Raghavan

Post by wellington wallace
Hi PA developers!
As you can see here https://github.com/wwmm/pulseeffects/issues/288

there

Post by wellington wallace
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

Post by wellington wallace
about how to do this. At this moment I am using null sinks to do the

audio

Post by wellington wallace
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

Post by wellington wallace
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

Post by wellington wallace
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

[Arun Raghavan]

Post by wellington wallace

Post by Arun Raghavan

Post by wellington wallace
Hi PA developers!
As you can see here https://github.com/wwmm/pulseeffects/issues/288

there

Post by wellington wallace
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

Post by wellington wallace
about how to do this. At this moment I am using null sinks to do the

audio

Post by wellington wallace
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

Post by wellington wallace
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

Post by wellington wallace
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.

It's the latter. I don't think we emit a sink-changed, but we should.

Cheers,
Arun