snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917.

[dev_submerge.ch]

Summary

The sample rate selection of snd_uaudio(4) at runtime was implicitly
relying on a specific order in the device config list. In case a default
was set through the hw.usb.uaudio.default_rate sysctl tunable, commit
42fdcd9fd917 removed a duplicate sample rate entry from that list, which
inadvertently broke sample rate selection at runtime.
Implement sample rate selection in a way that works for any order in the
device config list.

Reported by: Lexi Winter <[e-mail]>

[dev_submerge.ch]

This passed some manual tests, setting hw.usb.uaudio.default_rate to different values, re-plug the uaudio device and try various sample rates (vchans disabled).

Lexi, could you check whether this patch fixes your problems with hw.usb.uaudio.default_rate set in /boot/loader.conf?

Christos, please have a close look at the loop I changed there. My intention was to get the same behavior as before rG42fdcd9fd917, when the order of entries was

1. Default sample rate, if set through hw.usb.uaudio.default_rate.
2. All supported sample rates in descending order, including default (duplicate entry).

The order of entries should become irrelevant with this patch. Selected entry would be:

1. Matching sample rate, if supported.
2. Closest sample rate greater than requested, if no match.
3. Closest sample rate if all supported ones are smaller than requested.

We probably have to MFC this together with rG42fdcd9fd917.

[lexi_le-fay.org]

In D44051#1005057, @dev_submerge.ch wrote:

Lexi, could you check whether this patch fixes your problems with hw.usb.uaudio.default_rate set in /boot/loader.conf?

i've tested this on top of 61b88a230bac766f55984d8d33b98845d2b0d1a9 (main as of this morning) and it looks good: audio works even with the offending lines in /boot/loader.conf.

[christos]

LGTM. The only thing I'd point out is that it would be better to have a brief description of the code in the commit message.

[dev_submerge.ch]

In D44051#1005595, @christos wrote:

LGTM. The only thing I'd point out is that it would be better to have a brief description of the code in the commit message.

I don't exactly get what you would add to the commit message? But since I have to leave the commit to you anyway (thanks BTW), feel free to add a description to the message.

[christos]

In D44051#1005668, @dev_submerge.ch wrote:

In D44051#1005595, @christos wrote:

LGTM. The only thing I'd point out is that it would be better to have a brief description of the code in the commit message.

I don't exactly get what you would add to the commit message? But since I have to leave the commit to you anyway (thanks BTW), feel free to add a description to the message.

I mean that it'd be more helpful to have a more descriptive message than " Implement sample rate selection in a more robust way".

[dev_submerge.ch]

In D44051#1005669, @christos wrote:

I mean that it'd be more helpful to have a more descriptive message than " Implement sample rate selection in a more robust way".

Better? There's really not much more to describe, as we don't change behavior apart from the fix.