[GADGET] f_uac2: decoupling bNrChannels from bmChannelConfig?

[kaf@nwlink.com]

I've been looking at how f_uac2 determines bNrChannels. The current 
implementation derives the channel count from the population count of 
bmChannelConfig. Since the UAC2 channel location bitmap has only 27 
assignable speaker-position bits (bits 27–30 are reserved, and bit 31 
indicates raw data), this limits the advertised channel count to 27.

While investigating this, I noticed that commercial UAC2 devices (for 
example, the Allen & Heath Qu-5 mixer) advertise bNrChannels=32 while 
leaving bmChannelConfig=0. Linux enumerates that device as a 32-channel 
UAC2 interface.  This also appears to be consistent with the UAC2 
specification.  My use case is generic multichannel data transport 
rather than spatial audio, so a zero bmChannelConfig appears 
semantically appropriate.

To test this approach, I modified f_uac2 to advertise an explicit 
bNrChannels independent of bmChannelConfig, with bmChannelConfig=0. I 
also updated the gadget-side ALSA runtime accordingly.  Linux and macOS 
both enumerated the modified gadget correctly, and end-to-end streaming 
worked successfully via alsaloop.  I repeated the experiment with up to 
96 channels, and both hosts continued to enumerate and stream correctly.

Before investing additional effort, I'd like to understand whether this 
direction is consistent with the intent of the UAC2 gadget 
implementation.  Is the coupling from bmChannelConfig to bNrChannels an 
intentional design decision, or simply a convenient implementation given 
the existing ConfigFS interface?  Are there compatibility concerns that 
motivated coupling bNrChannels to the channel bitmap?

Thanks,
Kyle