[pulseaudio-discuss] Play audio files of high sample rates without hassle

[Tanu Kaskinen]

On Sat, 2016-11-26 at 12:54 +0100, Erwan JACQ wrote:
> I have a sound card Focusrite Scarlett 2i2 USB with a DAC supporting
> many sample rates : 44100, 48000, 88200, 96000, 176400, 192000 Hz
> 
> However, pulseaudio can only switch at runtime between 2 sample rates,
> defined by default-sample-rate and alternate-sample-rate in the daemon
> config file.
> 
> I don't understand this limitation. 
> - It's very painful when you want to play successively audio files of
> different sample rates. You have to kill pulseaudio daemon, change its
> conf, then restart it.
> - It's not efficient quality wise to resample 192000Hz audio to 48kHz.
> It's rejecting above average audio uses.
> - It's not efficient performance wise to do resampling if this can be
> avoided because hardware doesn't need it.
> - Pulseaudio can know all the supported sample rates of my sound card
> (ie: $cat /proc/asound/card2/stream0) so pulseaudio could dynamically
> switch to the proper sample rate.
> 
> I tried a little hack in src/pulsecore/sink.c and source.c to let
> pulseaudio ask the desired sample rate rather than to be limited to
> default-sample-rate and alternate-sample-rate and it seems to work.
> 
> Now, if I play audio files successively with a single application, the
> sample rate of the hardware is changed  dynamically for each audio file
> for each audio file.
> 
> Of course if an audio stream is already playing, the sample rate cannot
> change (there is a safeguard in the pulseaudio code). But this is
> already a limitation already in the actual behavior.
> 
> So in the end, it's working the same as now, except that the first audio
> stream can use a higher sample rate than the default/alternate sample
> rates.
> 
> Did I miss something?

The dynamic rate switching was added to deal specifically with the most
common case: switching between 44100 Hz and 48000 Hz. It's not that
supporting a more flexible policy is necessarily undesirable, it's just
that nobody has been interested enough to provide patches.

One reason why we don't simply try to switch to whatever rate streams
happen to have is that we don't want to end up in a situation where one
stream causes the sink to run at 8000 Hz and then an overlapping higher
quality stream appears and suffers from the very low sink rate.

So, if we relax the rate restrictions, we need to add at least a limit
for how low rates we accept. I don't remember if there were any other
considerations when this feature was discussed. If you provide patches
for improving the rate switching policy, at this point I don't see any
reason why such feature would be rejected.

-- 
Tanu

https://www.patreon.com/tanuk