Hi Wesley, On Wed Mar 19, 2025 at 1:51 AM CET, Wesley Cheng wrote: > Requesting to see if we can get some Acked-By tags, and merge on usb-next. > > Several Qualcomm based chipsets can support USB audio offloading to a > dedicated audio DSP, which can take over issuing transfers to the USB > host controller. The intention is to reduce the load on the main > processors in the SoC, and allow them to be placed into lower power modes. > There are several parts to this design: > 1. Adding ASoC binding layer > 2. Create a USB backend for Q6DSP > 3. Introduce XHCI interrupter support > 4. Create vendor ops for the USB SND driver > I was able to test this series (v35) on SM6350/SM7225 Fairphone 4 smartphone and it appears to work as expected! Based on the sm8350 branch you shared[0] I added similar dts bits for my device, I've pushed that branch here[1] for reference. [0] https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/commits/usb_audio_offload/ [1] https://github.com/sm6350-mainline/linux/commits/sm6350-6.14-wip-usb-snd-offload/ And I've used these commands to test: fairphone-4:~$ amixer -c0 cset name='USB Mixer MultiMedia2' On fairphone-4:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: F4 [Fairphone 4], device 0: MultiMedia1 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: F4 [Fairphone 4], device 1: MultiMedia2 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Audio [Hi-Res Audio], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 fairphone-4:~$ ffmpeg -i test.m4a -acodec pcm_s16le test.wav fairphone-4:~$ aplay --device=plughw:0,1 Music/test.wav Playing WAVE 'Music/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo And then music was coming out of these headphones connected via a USB-C to 3.5mm dongle. Every time I'm starting playback this error appears in dmesg, do you also see this on your test setup? [ 1336.081525] q6afe-dai 3000000.remoteproc:glink-edge:apr:service@4:dais: AFE Port already open And if I'm not mistaken it's possible to check that actually the offload path is getting used by checking the interrupt counts of the xhci-hcd interrupt. With regular USB audio card playback there's many interrupts per second happening: fairphone-4:~$ aplay --device=plughw:1,0 Music/test.wav # regular USB fairphone-4:~$ cat /proc/interrupts | grep -i usb 188: 137524 0 0 0 0 0 0 0 GICv3 165 Level xhci-hcd:usb1 fairphone-4:~$ cat /proc/interrupts | grep -i usb 188: 137591 0 0 0 0 0 0 0 GICv3 165 Level xhci-hcd:usb1 And with the offload card during playback there's no interrupts happening (just a few when initially starting playback): fairphone-4:~$ aplay --device=plughw:0,1 Music/test.wav # offload fairphone-4:~$ cat /proc/interrupts | grep -i usb 188: 141947 0 0 0 0 0 0 0 GICv3 165 Level xhci-hcd:usb1 fairphone-4:~$ cat /proc/interrupts | grep -i usb 188: 141947 0 0 0 0 0 0 0 GICv3 165 Level xhci-hcd:usb1 Let me know what you think about the message in dmesg I mentioned above. Regards Luca
