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
