Hi Pierre/Amadeusz, On 7/8/2024 4:16 PM, Wesley Cheng wrote: > 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? So I reworked the series a bit with respects to the kcontrols that we had, and I simplified it for the next submission. I went ahead and just have a read only kcontrol residing in the USB SND device and will implement #1 above: / # tinymix -D 1 contents Number of controls: 9 ctl type num name value 0 INT 2 Capture Channel Map 0, 0 (range 0->36) 1 INT 2 Playback Channel Map 0, 0 (range 0->36) 2 BOOL 1 Headset Capture Switch On 3 INT 1 Headset Capture Volume 10 (range 0->13) 4 BOOL 1 Sidetone Playback Switch On 5 INT 1 Sidetone Playback Volume 4096 (range 0->8192) 6 BOOL 1 Headset Playback Switch On 7 INT 2 Headset Playback Volume 20, 20 (range 0->24) 8 INT 2 USB Offload Playback Route PCM#0 0, 0 (range -1->255) If there is an available audio offload path, then the value will show the card and pcm index that it is mapped to. That way the application will know which card/pcm device to open from there. In the above example, the offload path is mapped to card#0 pcm#0. If there is no offload path available, it will show -1, -1. For now, I removed the control that allows for explicit selection of which USB card and PCM device to offload, and will take this up on a separate series as we see fit. The codebase I have now will select the last USB headset plugged in for offloading. Will clean up the changes and submit a new revision with the other feedback included as well. Thanks Wesley Cheng > >> 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 >
