ALSA: a device setup that names no sample rate opens at the lowest rate the device lists, 8 kHz

Detailed steps on how to reproduce the bug

1. On Linux with ALSA (PipeWire's default device here, but any device that lists rates from 8 kHz), build any JUCE application that opens its audio device through AudioDeviceManager::initialise() with no saved state, the DemoRunner for example.
2. Run it for the first time and read the sample rate the device opened at.

What is the expected behaviour?

AudioDeviceSetup::sampleRate is documented as "A value of 0 indicates that you don't care what rate is used, and the device will choose a sensible rate for you." JUCE 8 chose the device's current rate when listed, else the lowest rate at or above 44.1 kHz (AudioDeviceManager::chooseBestSampleRate).

What is the actual behaviour?

The device opens at 8 kHz.

AudioDeviceManager::setAudioDeviceSetup in 9.0.2 resolves a zero rate to the device's current rate and then takes the nearest listed rate:

currentSetup.sampleRate = findNearestValue (Span { currentAudioDevice->getAvailableSampleRates() },
                                            getNonZeroOrDefault (currentSetup.sampleRate, currentAudioDevice->getCurrentSampleRate()));

ALSAAudioIODevice::getCurrentSampleRate() returns internal.sampleRate, which is 0 until the device has been opened (juce_ALSA_linux.cpp), so on a first open the search runs from zero and lands on the lowest rate the device lists, 8 kHz on ALSA. CoreAudio reports the hardware's rate before opening, so macOS is unaffected. 9.0.1 had the same outcome by a different route (the search from zero applied to the buffer size too, giving 16 samples), which 9.0.2 fixes for the buffer size but not for the rate on a device that reports none.

Observed on a user's Ubuntu 24.04 with a PipeWire default device: a JUCE host built on 9.0.1 opened at 8 kHz and 16 samples on first launch with no choice made in any settings page, and saved that state for every later launch.

The mock device in AudioDeviceManagerTests reports no rate before opening, as ALSA does, so a unit test shows it once the mock lists a rate under 44.1 kHz: a setup naming no rate on that device opens at 22050 Hz. The fix that works here falls back, when the device reports no current rate, to the lowest rate it lists at or above 44.1 kHz. Pull request to follow, with that test.

Operating systems

Linux

What versions of the operating systems?

Ubuntu 24.04 (reported)

Architectures

x86_64

Stacktrace

None; nothing crashes.

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

A JUCE host built on AudioDeviceManager.

Testing on the develop branch

The bug is present on the develop branch (72782788c, 9.0.2)

Code of Conduct

• I agree to follow the Code of Conduct