sound: Simplify vchan_getparentchannel()

[christos]

Summary

Since FILLME ("sound: Allocate vchans on-demand") introduced the
"primary" channel sub-list, we can use it in vchan_getparentchannel() to
loop only through the primary channels, which is what we are looking for
anyway.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

[christos]

Bump.

[dev_submerge.ch]

Not a consequence of your changes here, but it seems we only set the vchan settings on the first channel per direction. There could be multiple, right?

IIRC, there's only one or two sound drivers that support multiple channels per direction. Maybe we should evaluate whether that's actually required and worth the complication it causes throughout the sound module.

[christos]

In D47918#1099644, @dev_submerge.ch wrote:

Not a consequence of your changes here, but it seems we only set the vchan settings on the first channel per direction. There could be multiple, right?

IIRC, there's only one or two sound drivers that support multiple channels per direction. Maybe we should evaluate whether that's actually required and worth the complication it causes throughout the sound module.

There are more places in pcm/ where we always pick the first primary channel. I guess we could implement some heuristics, like choosing the first non-busy channel, or else fall back to the first channel, or the channel with the least vchans, in order to balance things out, but that would require multiple changes throughout sound(4), so we could discuss this further in an email.

[dev_submerge.ch]

In D47918#1100131, @christos wrote:

In D47918#1099644, @dev_submerge.ch wrote:

Not a consequence of your changes here, but it seems we only set the vchan settings on the first channel per direction. There could be multiple, right?

IIRC, there's only one or two sound drivers that support multiple channels per direction. Maybe we should evaluate whether that's actually required and worth the complication it causes throughout the sound module.

There are more places in pcm/ where we always pick the first primary channel. I guess we could implement some heuristics, like choosing the first non-busy channel, or else fall back to the first channel, or the channel with the least vchans, in order to balance things out, but that would require multiple changes throughout sound(4), so we could discuss this further in an email.

Just to clarify, my general proposal would be to see whether we can limit all drivers to at most one primary channel per direction. If that's possible, the primary channel list reduces to two fields (one per direction), and handling them should become easier in the places you mention. It's a separate discussion though, agreed.

My point regarding the code here is that we change settings for only one of the primary channels, while we should do this for all primary channels to keep them consistent. Which is an example of where it would be easier to have only one primary channel per direction.

[christos]

In D47918#1100168, @dev_submerge.ch wrote:

In D47918#1100131, @christos wrote:

In D47918#1099644, @dev_submerge.ch wrote:

Not a consequence of your changes here, but it seems we only set the vchan settings on the first channel per direction. There could be multiple, right?

IIRC, there's only one or two sound drivers that support multiple channels per direction. Maybe we should evaluate whether that's actually required and worth the complication it causes throughout the sound module.

There are more places in pcm/ where we always pick the first primary channel. I guess we could implement some heuristics, like choosing the first non-busy channel, or else fall back to the first channel, or the channel with the least vchans, in order to balance things out, but that would require multiple changes throughout sound(4), so we could discuss this further in an email.

Just to clarify, my general proposal would be to see whether we can limit all drivers to at most one primary channel per direction. If that's possible, the primary channel list reduces to two fields (one per direction), and handling them should become easier in the places you mention. It's a separate discussion though, agreed.

My point regarding the code here is that we change settings for only one of the primary channels, while we should do this for all primary channels to keep them consistent. Which is an example of where it would be easier to have only one primary channel per direction.

I guess one way to go about addressing this would be to actually get rid of vchan_getparentchannel() altogether, and instead wrap the related sysctl codes around a loop through the primary channel list (see D47917). For sysctl_dev_pcm_vchanrate() and sysctl_dev_pcm_vchanformat() this is very trivial to implement. For sysctl_dev_pcm_vchanmode() it's probably trickier, because the code seems to fetch the mode from the primary channel directly; maybe this is something we should store in snddev_info instead, like vchanformat/vchanrate?

[christos]

In D47918#1100261, @christos wrote:

In D47918#1100168, @dev_submerge.ch wrote:

In D47918#1100131, @christos wrote:

In D47918#1099644, @dev_submerge.ch wrote:

Not a consequence of your changes here, but it seems we only set the vchan settings on the first channel per direction. There could be multiple, right?

IIRC, there's only one or two sound drivers that support multiple channels per direction. Maybe we should evaluate whether that's actually required and worth the complication it causes throughout the sound module.

There are more places in pcm/ where we always pick the first primary channel. I guess we could implement some heuristics, like choosing the first non-busy channel, or else fall back to the first channel, or the channel with the least vchans, in order to balance things out, but that would require multiple changes throughout sound(4), so we could discuss this further in an email.

Just to clarify, my general proposal would be to see whether we can limit all drivers to at most one primary channel per direction. If that's possible, the primary channel list reduces to two fields (one per direction), and handling them should become easier in the places you mention. It's a separate discussion though, agreed.

My point regarding the code here is that we change settings for only one of the primary channels, while we should do this for all primary channels to keep them consistent. Which is an example of where it would be easier to have only one primary channel per direction.

I guess one way to go about addressing this would be to actually get rid of vchan_getparentchannel() altogether, and instead wrap the related sysctl codes around a loop through the primary channel list (see D47917). For sysctl_dev_pcm_vchanrate() and sysctl_dev_pcm_vchanformat() this is very trivial to implement. For sysctl_dev_pcm_vchanmode() it's probably trickier, because the code seems to fetch the mode from the primary channel directly; maybe this is something we should store in snddev_info instead, like vchanformat/vchanrate?

D48335 for the vchanmode issue.

[christos]

And D48336 for the multiple primary channels issue. Closing this.