Bug 1219906

Summary:	PulseAudio device advertises sample rates which cannot actually be used
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Hadrien Grasland <grasland>
Component:	Sound	Assignee:	Takashi Iwai <tiwai>
Status:	RESOLVED UPSTREAM	QA Contact:	E-mail List <qa-bugs>
Severity:	Minor
Priority:	P5 - None
Version:	Current
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE Tumbleweed
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Hadrien Grasland 2024-02-14 08:53:18 UTC

My computer has multiple audio outputs, but most of the time I want to use my higher-end USB interface (Arturia AudioFuse), which maps into ALSA device hw:2,0.

Unfortunately, several of my pro audio applications (MuseScore, Audacity, VCV Rack) cannot emit audio over the default ALSA output device, which goes through pulseaudio, when that audio output is selected in the pulseaudio GUI.

Instead, when I attempt to start playback, the playback GUI just gets stuck without any audible sound going through the speakers.

I have experimented a bit with Audacity and observed that I can get sound to work by performing any of the following three audio output configuration changes:

- Switch PulseAudio's active device from AudioFuse to HDMI, which sends audio through the monitor's (horrible) built-in speakers.
- Switch Audacity's ALSA output from `default` to `hw:2,0` (i.e. directly send audio to the underlying USB interface without going through pulseaudio).
- Switch Audacity's sampling rate from 44100Hz to 96000Hz, which is the actual sampling rate that `hw:2,0` is configured to use.

This suggests that although the `default` ALSA device and the `pulse` device it points to both advertise support for the 44100Hz sampling rate, it is actually impossible to send 44100Hz audio to them.

Indeed, unlike the `default` and `pulse` devices, the underlying `hw:2,0` device only exposes support for the 96000Hz sampling rate. So on this device 44100Hz audio would only be possible via resampling. Maybe PulseAudio can actually perform such resampling, but it does not seem to be working here, and attempting to use one of these sampling rates just breaks the audio apps...

I think PulseAudio should do either of the following here:

1. Actually resample audio to the selected sampling rate
2. Not expose support for sampling rates which do not work

Comment 1 Hadrien Grasland 2024-02-14 09:22:00 UTC

After closer investigation, this problem only appears when pulseaudio is configured to use a default-sample-rate of 96000 (I configured that a while ago).

If default-sample-rate is 44100, then for some strange reason all hardware-supported sample rates become available on both the hw:2,0 and default/pulse devices.

I have no idea why setting pulseaudio's default-sample-rate to a non-default value breaks hardware support for other sample rates, but well, at least for other affected people this provides a workaround...

Comment 2 Takashi Iwai 2024-02-14 09:48:36 UTC

I can't say exactly unless getting the hardware details, but it's possible that there can be some hardware restriction about the sample rate setup for your USB-audio device, e.g. full-duplex is only with reduced rates or limited to certain sample formats.  The kernel driver applies such restrictions dynamically, but for the application side, it's hard to know everything (basically it can do only trial-and-error with different configs).

That said, leaving the default to the lower value should fix your case.

Comment 3 Hadrien Grasland 2024-02-14 12:47:47 UTC

I can provide any hardware detail you need. What would you want, an `lsusb -v` of the audio interface? A tarball of the readable pseudofiles in /proc/asound?

In any case, this issue has indeed become a lot less pressing for me now that I have a workaround and am convinced that this will only affect people with unusual pulseaudio/hardware configurations. I'm demoting the issue's severity accordingly.

Back in the day, I set pulseaudio's default-sample-rate because this was seemingly the only way to get a full 96kHz audio input & processing workflow. Since then I've switched to using JACK for most of my advanced audio processing needs (which has its own sample rate control), and pulseaudio has gained avoid-resampling mode which allows apps to pick the audio sample rate when they are the only ones using the device, so tweaking default-sample-rate is a lot less useful that it has been in the past.

What still puzzles me and seems worth fixing, however, is the fact that in certain hardware+pulseaudio configurations, the pulseaudio ALSA device exposes sampling rates that it cannot handle (not even via resampling). This is particularly problematic with apps like MuseScore 4 that have minimalistic audio output options, and do not allow you to pick the audio output device and sample rate: if these apps pick the wrong settings, then they won't be able to emit sound at all...

Comment 4 Takashi Iwai 2024-02-14 12:56:06 UTC

The resampling should happen in PA.  I suspect it's rather the driver that doesn't work with the given rate under certain situations.  But the fact that the driver declines the parameter is the correct and expected behavior; it's a result of the hardware restriction.

So, there is some room for improvement in PA side.  But if you want to continue tracking that, I'd suggest rather to open an upstream issue.  It's no downstream problem, after all.

Other than that, we may close as WORKSFORME.

Comment 5 Hadrien Grasland 2024-02-14 13:56:58 UTC

If you are convinced that this is not SUSE-specific (either a pulse issue or an ALSA driver/hardware issue), then indeed the best course of action is to close this report and take it to the pulseaudio issue tracker next.