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:
USB SND device is offload capable (ASoC card and PCM index)- Fetches associated (mapped) ASoC platform card and PCM index (read only)
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