Bug 99437

Summary:	module-combine fails to set best sample rate
Product:	PulseAudio	Reporter:	Julian Hughes <julianhughes>
Component:	modules	Assignee:	pulseaudio-bugs
Status:	RESOLVED MOVED	QA Contact:	pulseaudio-bugs
Severity:	normal
Priority:	medium	CC:	lennart
Version:	unspecified
Hardware:	All
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Julian Hughes 2017-01-17 09:41:27 UTC

$ pulseaudio --version
pulseaudio 5.0

$ uname -a
Linux pi 4.4.0-1-rpi #1 Debian 4.4.6-1+rpi14 (2016-05-05) armv6l GNU/Linux

I'm successfully using module-combine as follows (from my /etc/pulse/default.pa):

"load-module module-alsa-sink device="hw:0,0" sink_name=dac0
load-module module-alsa-sink device="hw:1,0" sink_name=dac1
load-module module-combine sink_name=combo slaves=dac0,dac1
set-default-sink combo"

(each DAC outputs the same 2 channel audio to a different amplifier).

Both USB DACs are identical and support the following rates:
96000, 88200, 48000, 44100, 32000.
My /etc/pulse/daemon.conf is the Debian package default so default sample rate is 44100 and the alternative is 48000.

If I use just one dac with an unmodified /etc/pulse/default.pa then the sample rate is successfully switched between 44100 and 48000 where appropriate and possible.

When I use module-combine and two dacs the virtual sink/device only uses the default rate set in /etc/pulse/daemon.conf. If uncomment the default and alternative rates and set them to different supported values and restart pulseaudio then this new default rate is used, but the virtual/combined device only ever uses the specified default.

This issue came up in 2009, see https://lists.freedesktop.org/archives/pulseaudio-discuss/2009-March/003232.html but the submitted patch was problematic and nothing came of it. However the following was stated:

"Otherwise file a feature request bug and I
will look into it eventually.

Lennart

--
Lennart Poettering "

Would now be eventually? :-)

I couldn't find any reference to this bug ever being fixed in newer versions.

Hope you can fix this, thanks!

Comment 1 Tanu Kaskinen 2017-01-23 09:27:51 UTC

Thanks for the report!

(In reply to Julian Hughes from comment #0)
> "Otherwise file a feature request bug and I
> will look into it eventually.
> 
> Lennart"
> 
> Would now be eventually? :-)

Well, Lennart isn't working on PulseAudio any more, so he's not likely to look into this. As for me, I have a bunch of other bugs lined up already, so I don't expect to have time for this bug any time soon. But maybe eventually...

> I couldn't find any reference to this bug ever being fixed in newer versions.

I don't remember this problem being reported before, and this is certainly still an issue with the newest release.

Comment 2 Julian Hughes 2017-01-23 10:59:57 UTC

Hello Tanu, thanks for replying.

Yesterday I upgraded my Pi (version 1 Model B) to newest Debian (raspbian) version available to check:

$ uname -a
Linux pi 4.4.0-1-rpi #1 Debian 4.4.6-1+rpi14 (2016-05-05) armv6l GNU/Linux
$ pulseaudio --version
pulseaudio 9.0

and confirm the issue still exists in 9.0.  I couldn't check pulseaudio version 10 so thanks for confirming the situation is unchanged.

Actually on x86 or amd64 PC I would probably not file a bug for this because the pulseaudio sample rate converter options are very good. In theory the same options are available on the Pi.  However, in practice, the Pi has very limited choices of converter due to the modest hardware. For me anything more demanding than "resample-method = speex-float-1" causes lots of ugly dropouts and even speex-float-1 can be too much with some network streams such as HLS i.e. BBC's HTTP Live Streaming. I assume other embedded devices will have similar problems.  It would be great to just the pass the stream to the DACs with rate unchanged.

Anyway, thanks again for your attention.  I will habitually check for progress and may write again in 2025 :-)

Comment 3 GitLab Migration User 2018-07-30 10:07:46 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/221.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.