Hi Pierre,
On 3/9/2023 4:37 PM, Pierre-Louis Bossart wrote:
Create vendor ops for the USB SND driver: qc_audio_offload: This particular driver has several components associated with it:
- QMI stream request handler
- XHCI interrupter and resource management
- audio DSP memory management
so how does this 'qc_audio_offload' interface with 'q6usb' described above? how are the roles different or complementary?
So in general you can think that the qc_audio_offload is a complement to the USB SND USB class driver, while q6usb is to ASoC. Since the ASoC
Humm, that is far from clear. I don't get how a something that interacts with the USB class driver can also be in charge of the audio DSP memory management.
This is because the USB class driver is the entity which is going to work with the USB HCD (XHCI) in this case to fetch the required addresses, and map that into memory accessible by the audio DSP. It would be odd to be doing that from the q6usb end, which is part of the ASoC layer.
framework doesn't have any communication with USB SND, the ASoC DPCM USB backend (q6usb) will have to be the entity that maintains what is going on in USB SND. That way, sessions initiated through the ASoC managed sound card can evaluate what is available based on information reported by q6usb.
qc_audio_offload and q6usb will have some interaction between each other. The majority of communication between qc_audio_offload and q6usb is reporting the device connection events.
It's already complicated to figure out how the DSP and USB class driver might interact and probe/timing dependencies, but with two additional drivers in the mix it's really hard to understand.
I did test some cases based on existence of both these drivers (qc_audio_offload and q6usb). If either one doesn't exist in the system, then the offload path would not work. I did improve some of these potential sequences in the latest revision, such as patch#28. This would address scenarios where the q6usb ASoC DPCM backend wasn't probed, while the USB SND (and qc_audio_offload) were still detecting device connections.
Once the Q6USB driver is probed, then the offload snd kcontrols would be created, and devices would be properly identified with the rediscover api.
Maybe ascii-art would help describe the concepts and types of information exchanged. Maintaining a consistent state across multiple drivers is not an easy task.
Hopefully this might help? I know its a lot to read through.
USB | ASoC -------------------------------------------------------------------- | _________________________ | |sm8250 platform card | | |_________________________| | | | | ___V____ ____V____ | |Q6USB | |Q6AFE | #5 | |"codec" | |"cpu" | | |________| |_________| | ^ | | #6 | ___V____ | |SOC-USB | ________ #1 ________ #7 | | |USB SND |<--->|QC offld|<------------>|________| |(card.c)| | |<---------- ^ |________| |________|___ #4 | | | ^ ^ | | | ___V__________________ | #2 | #2 | | | |APR/GLINK | __ V_______________V_____ | | | |______________________| |USB SND (endpoint.c) | | | | ^ |_________________________| | | | #8 | ^ | | | ___________V___________ | #3 | | |->|audio DSP | ___________V_____________ | | |_______________________| |XHCI HCD |<- | |_________________________| |
#1 - USB SND and QC offload: Initialization: - Register platform operations, to receive connect/disconnect events from USB SND. - QC offload creates a QMI handle, in order to receive QMI requests from the audio DSP.
Runtime: - USB SND passes along "struct snd_usb_audio" in order for QC offload to reference USB UAC desc parsing/USB SND helper APIs. - USB device disconnection events will result in clearing of the chip entry.
#2 - USB SND and QC offload endpoints: Runtime: - In the non-offloaded path, USB snd will utilize functions exposed by USB SND endpoint, to help with fetching USB EP references and queuing URBs. - In the offload path, qc offload will utilize the functions to fetch USB EP references, so that it can use that information to query the XHCI HCD. - Likewise, both will clean up endpoints when audio stream is not in use.
#3 - XHCI HCD: Initialization: - During XHCI probe timing, when the USB HCD is added to the system, it will also initialize the secondary event rings.
Runtime: - During USB device plug ins/outs, allocates device slot, assigns eps, and initializes transfer rings.
#4 - QC offload and XHCI: Runtime: - QC offload needs to reference the transfer ring and secondary event ring addresses by executing XHCI offload management APIs. - This happens when audio DSP receives a USB QMI stream request.
#5 - ASoC components: Initialization: - The SM8250 platform sound card driver fetches DT node entries defining the ASoC links. This chain/link has the components involved for a particular Q6AFE path. (not only USB offload) - "cpu" - this is the ASoC CPU DAI that handles interaction with the Q6 DSP's audio protocol. (AFE ports) - "codec" - the ASoC codec (backend) DAI defined - Registers ASoC platform sound card based on links defined in the DT node. - Probes DAI components involved, ie Q6USB and Q6AFE
Runtime: - Q6AFE has the bulk of the interaction w/ the audio DSP to start an audio session, such as issuing AFE port start commands (part of the protocol used to communicate the audio session info) - Q6USB will be there to now check for if format requested is supported by the device, and maintain offloading status.
#6 - Q6USB and SOC-USB: Initialization: - Q6USB will query QC offload for USB device connection states. (through soc-usb) - Creates a SOC USB entry, that carries information about resources, such as audio DSP memory information and requested XHCI event ring index.
Runtime: - SOC-USB will receive connect/disconnect events and propagate to Q6USB. - Q6USB makes devices available for offloading based on these events. - Sets Q6AFE port configurations to select the USB SND card# and PCM#.
#7 - SOC-USB and QC offload: Initialization: - Rediscover USB SND devices when the SOC-USB entry is created (if needed) - For situations where the Q6USB DAI hasn't been probed.
Runtime: - Propagate connect/disconnect events.
#8 - audio DSP and QC offload: Runtime: - Handle QMI requests coming from audio DSP. These requests come AFTER the Q6AFE port is opened by the Q6AFE DAI(#6) - Returns memory information about resources allocated by XHCI. - Enables audio playback when this QMI transaction is completed.
When the audio DSP wants to enable a playback stream, the request is first received by the ASoC platform sound card. Depending on the selected route, ASoC will bring up the individual DAIs in the path. The Q6USB backend DAI will send an AFE port start command (with enabling the USB playback path), and the audio DSP will handle the request accordingly.
Part of the AFE USB port start handling will have an exchange of control messages using the QMI protocol. The qc_audio_offload driver will populate the buffer information:
- Event ring base address
- EP transfer ring base address
and pass it along to the audio DSP. All endpoint management will now be handed over to the DSP, and the main processor is not involved in transfers.
Overall, implementing this feature will still expose separate sound card and PCM devices for both the platorm card and USB audio device: 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D SM8250-MTP-WCD9380-WSA8810-VA-DMIC 1 [Audio ]: USB-Audio - USB Audio Generic USB Audio at usb-xhci-hcd.1.auto-1.4, high speed
This is to ensure that userspace ALSA entities can decide which route to take when executing the audio playback. In the above, if card#1 is selected, then USB audio data will take the legacy path over the USB PCM drivers, etc...
I already voiced my concerns about exposing two cards, each with their own set of volume controls with the same device. It would be much better to have an additional offloaded PCM device for card0...
But if the consensus is to have two cards, it's still not clear how the routing would be selected. In the case where there are two USB audio devices attached, the offloaded path would only support one of the two. How would userspace know which of the two is selected?
With patch#24: https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc....
Now, userspace can at least choose which device it wants to offload. Part of doing that would mean userspace knows what USB SND card devices are available, so it is aware of which devices are shared (between the offload and USB SND path)
And how would userspace know the difference anyways between two physical devices attached to the platform with no offload, and one physical device with one additional offload path? The names you selected can't be used to identify that card1 is the optimized version of card0.
Is userspace currently able to differentiate between cards that are created by USB SND versus ASoC? How complex can the userspace card discovery be? Can it query kcontrols at this point in time? If so, maybe we can change the names of the newly added ones to reflect that it is an offload device?
SND kcontrol names are currently: Q6USB offload status Q6USB offload SND device select
I must admit I've never seen kcontrols being used to identify what the card is, and in this case it's a pretend-card that's just an improved version of another. It might be easier to use something else, such as the component strings.
Its not exactly a pretend card, right? This is part of the overall platform sound card we have in the system. At the moment, I'm only testing by adding the USB audio routing, but there can be several ASoC links defined in the overall platform card.
The Q6AFE CPU DAI has multiple audio AFE "ports" they can handle. USB is only one of those.
Before we review low-level kernel plumbing, it would be good to give a better overview of how userspace applications are supposed to interact with the cards and identify the offloaded path. Testing with tinyplay/tinymix is fine, but that's a developer-level or CI unit test. we've got to see the broader picture of how a sound server would use this USB offload capability.
Sure, I think that is fine. I was hoping that at least adding some of the new kcontrols would help userspace make use of this path in general, but we can add more information if required.
Can I ask if this solution has been used with a complete userspace stack already? I could see how this might be used with a relatively fixed
Its been used only with the Android HAL.
Android HAL, where the platform and routing are relatively controlled. I don't see how a more generic audio server would deal with the discovery and routing.
This is why your input is helpful, since it provides another use case that wasn't considered. I think in our previous discussions the tagging possibility was a good idea, and was hoping that it could help. Could tag all USB SND cards to the platform sound card as well, and if the power saving path is chosen, it would issue the playback on the platform sound card. (if not in use)
In this case, the offload path wouldn't be the default routing, and only enabled for power optimized path.
Thanks Wesley Cheng