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.

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.

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.

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.

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".

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.