Not very elegant, but the whole iteration method here is somewhat crude. The default_rate sysctl already acts like a default, and does not prevent other sample rates from the list. Leave it unchanged.

For the others, I tested with a bunch of different USB audio interfaces that:

• Leaving defaults for default_bits (32) and default_channels (0) acts the same as before.
• Setting defaults selects the wanted configurations if they match.
• Setting defaults does not prevent other (higher) bits and channels configurations to be detected (improvement).
• The special behavior regarding USB 1.1 devices is preserved (no more than 4 channels by default, more channels if default_channels >= channels).

Please note that it's not possible to solve all situations with global settings like this. But this is already improves flexibility, and thus utility of these sysctl tunables.

If the defaults can only take values between a certain range (i.e channels can be up to 64 and bits up to 32), and this patch also allows the driver to detect configs with higher values than the default, why don't we just start from the maximum value for both channels and bits instead of doing this hack, since we know that the default_*s are going to fall into those ranges anyway? Since in the iteration we try all possible combinations, we know that one of the configurations will end up being what the user would have defined using the defaults. This way we might not even need those controls at all. Also, following the same logic, do we need default_rate if the driver will only create channels for supported rates?

Correct me if I am missing something here, but I don't see where else those tunable values are used except in uaudio_chan_fill_info() which seems to search for and create configs for all supported channel/bits/rate combinations, and just includes a case where it tests if the user-supplied value is supported.

Can you test whether this patch produces the same configurations for your devices (it's diff'd against the original version)? It gets rid of all default_* sysctls and detects configs starting from the max supported channels/bits and rates.
https://reviews.freebsd.org/P627

In D43679#997248, @christos wrote:

If the defaults can only take values between a certain range (i.e channels can be up to 64 and bits up to 32), and this patch also allows the driver to detect configs with higher values than the default, why don't we just start from the maximum value for both channels and bits instead of doing this hack, since we know that the default_*s are going to fall into those ranges anyway? Since in the iteration we try all possible combinations, we know that one of the configurations will end up being what the user would have defined using the defaults. This way we might not even need those controls at all. Also, following the same logic, do we need default_rate if the driver will only create channels for supported rates?

Correct me if I am missing something here, but I don't see where else those tunable values are used except in uaudio_chan_fill_info() which seems to search for and create configs for all supported channel/bits/rate combinations, and just includes a case where it tests if the user-supplied value is supported.

Order matters here! It's a bit hard to follow uaudio_chan_fill_info_sub() and its side effects. But AFAIK the first matching configuration is selected for use. And I think the other configurations are detected, but not used. Or at least I would not know how to change the configuration as long as the driver is attached. Except for the sample rate, but only in the range of the selected configuration from the USB descriptor.

An example: My RME BabyFace has a 10 in 12 out channel configuration, and a 2 in 2 out channel configuration. Let's say I want to use the 2 in 2 out configuration because most audio applications cannot cope with 12 channels, and I can't route everything through Jack. I also have an SPL Crimson, 6 in 6 out. And I have a Focusrite Scarlett 18 in 20 out.

Current implementation: If I set default_channels=2, only the BabyFace is detected. I can set default_channels=6, and then I get both the BabyFace and the Crimson. But no way to use the Scarlett at the same time.

My proposal: I can set default_channels=2, and get all of them detected correctly. Caveat: Any other uaudio device with a 2 channel configuration will have that configuration selected.

Your proposal: I cannot use the 2 in 2 out channel configuration at all. It always selects 10 in 12 out.

In D43679#997388, @dev_submerge.ch wrote:

In D43679#997248, @christos wrote:

If the defaults can only take values between a certain range (i.e channels can be up to 64 and bits up to 32), and this patch also allows the driver to detect configs with higher values than the default, why don't we just start from the maximum value for both channels and bits instead of doing this hack, since we know that the default_*s are going to fall into those ranges anyway? Since in the iteration we try all possible combinations, we know that one of the configurations will end up being what the user would have defined using the defaults. This way we might not even need those controls at all. Also, following the same logic, do we need default_rate if the driver will only create channels for supported rates?

Correct me if I am missing something here, but I don't see where else those tunable values are used except in uaudio_chan_fill_info() which seems to search for and create configs for all supported channel/bits/rate combinations, and just includes a case where it tests if the user-supplied value is supported.

Order matters here! It's a bit hard to follow uaudio_chan_fill_info_sub() and its side effects. But AFAIK the first matching configuration is selected for use. And I think the other configurations are detected, but not used. Or at least I would not know how to change the configuration as long as the driver is attached. Except for the sample rate, but only in the range of the selected configuration from the USB descriptor.

An example: My RME BabyFace has a 10 in 12 out channel configuration, and a 2 in 2 out channel configuration. Let's say I want to use the 2 in 2 out configuration because most audio applications cannot cope with 12 channels, and I can't route everything through Jack. I also have an SPL Crimson, 6 in 6 out. And I have a Focusrite Scarlett 18 in 20 out.

Current implementation: If I set default_channels=2, only the BabyFace is detected. I can set default_channels=6, and then I get both the BabyFace and the Crimson. But no way to use the Scarlett at the same time.

My proposal: I can set default_channels=2, and get all of them detected correctly. Caveat: Any other uaudio device with a 2 channel configuration will have that configuration selected.

We may need to make these sysctls per-device instead of global. I can take care of this if we agree to go ahead with it.

Your proposal: I cannot use the 2 in 2 out channel configuration at all. It always selects 10 in 12 out.

Yeap, makes sense. I had forgot that the driver will use the first matching configuration instead of the best one.

In D43679#997460, @christos wrote:

In D43679#997388, @dev_submerge.ch wrote:

An example: My RME BabyFace has a 10 in 12 out channel configuration, and a 2 in 2 out channel configuration. Let's say I want to use the 2 in 2 out configuration because most audio applications cannot cope with 12 channels, and I can't route everything through Jack. I also have an SPL Crimson, 6 in 6 out. And I have a Focusrite Scarlett 18 in 20 out.

Current implementation: If I set default_channels=2, only the BabyFace is detected. I can set default_channels=6, and then I get both the BabyFace and the Crimson. But no way to use the Scarlett at the same time.

My proposal: I can set default_channels=2, and get all of them detected correctly. Caveat: Any other uaudio device with a 2 channel configuration will have that configuration selected.

We may need to make these sysctls per-device instead of global. I can take care of this if we agree to go ahead with it.

In my experiments with snd_hdspe(4) I wasn't able to make per device settings from e.g. /boot/loader.conf available at attach time. I think the way to go would be changing the selected configuration on request by the pcm infrastructure, similar to what is done in uaudio_chan_set_param_speed() for the sample rate. But maybe not now, that's probably a bigger endeavor.

In D43679#997498, @dev_submerge.ch wrote:

In D43679#997460, @christos wrote:

In D43679#997388, @dev_submerge.ch wrote:

An example: My RME BabyFace has a 10 in 12 out channel configuration, and a 2 in 2 out channel configuration. Let's say I want to use the 2 in 2 out configuration because most audio applications cannot cope with 12 channels, and I can't route everything through Jack. I also have an SPL Crimson, 6 in 6 out. And I have a Focusrite Scarlett 18 in 20 out.

Current implementation: If I set default_channels=2, only the BabyFace is detected. I can set default_channels=6, and then I get both the BabyFace and the Crimson. But no way to use the Scarlett at the same time.

My proposal: I can set default_channels=2, and get all of them detected correctly. Caveat: Any other uaudio device with a 2 channel configuration will have that configuration selected.

We may need to make these sysctls per-device instead of global. I can take care of this if we agree to go ahead with it.

In my experiments with snd_hdspe(4) I wasn't able to make per device settings from e.g. /boot/loader.conf available at attach time. I think the way to go would be changing the selected configuration on request by the pcm infrastructure, similar to what is done in uaudio_chan_set_param_speed() for the sample rate. But maybe not now, that's probably a bigger endeavor.

I agree.