On 7/4/2024 4:25 AM, Pierre-Louis Bossart wrote:
Just so I understand...is it really desired that userspace doesn't have the flexibility to choose which USB device is offloaded? I know it complicates what needs to be done, but it could be just an additional feature that can be added later on. Again, by default, we select the last USB headset plugged in to be enabled for offload by default.
If it chooses endpoint by itself perhaps you can send patch set without controls first? This has added benefit of less patches in series, making it easier to review and it won't block whole patch set by discussion on controls feature. Controls can be added in followup series.
We do need read-only controls for userspace to know that offload is possible and which card/device to use. That can be done in a first step assuming there's a single device plugged-in.
I agree, some kcontrol need to be present to at least determine:
1. USB SND device is offload capable (ASoC card and PCM index)- Fetches associated (mapped) ASoC platform card and PCM index (read only)
2. ASoC platform card offload status - Current offload status (read only)
Those would be the minimum kcontrols we could have at this time. I will remove the device selection part, and leave that for future discussions. Does this sound good, Amadeusz/Pierre?
Dealing with multiple devices and defining rules or configuration options to select the offloaded device is a second-level problem.
In most cases the only thing that will be offloaded is a headset anyways, so the selection could be rather static based on a vendor/system ID, all other USB devices would be ignored.
If the USB SND offload driver (ie qc_audio_offload) isn't compiled in, then it would be disabled. Do we need some over-arching mechanism to disable the offload functionality? Although, one thing I can see if I can add is some device classification within the USB offload vendor driver.
Thanks
Wesley Cheng