Re: [PATCH v30 00/30] Introduce QC USB SND audio offloading support

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 2024-12-03 9:38 PM, Wesley Cheng wrote:
> Hi Cezary,
> 
> On 12/3/2024 8:17 AM, Cezary Rojewski wrote:
>> On 2024-12-01 4:14 AM, Pierre-Louis Bossart wrote:
>>> Sorry to chime in late, I only look at email occasionally.

...

>>> The notion of two cards was agreed inside Intel as far back as 2018, when Rakesh first looked at USB offload.
>>
>>
>> Well, I believe a lot has changed since then, not sure if USB Audio Offload (UAOL) was even stable on the Windows solution back then. Obviously we want to incorporate what we have learned during all that time into our solution before it lands on upstream.
>>
> 
> Hard to comment further without more details on the lessons learnt you had on Windows.  I just want to make sure we're talking about the same feature here, because I see sprinkles of the xHCI audio sideband (section 7.9) on the Windows documentation without much details on how its implemented, which is different than what is presented here.

The comment was directed towards mention of Intel, 2018 and Rakesh. The 
decisions made then do not bind us, and current Intel's Audio team has a 
clean slide. Wanted to make sure it's clear.

>> UAOL is one of our priorities right now and some (e.g.: me) prefer to not pollute their mind with another approaches until what they have in mind is crystalized. In short, I'd vote for a approach where USB device has a ASoC representative in sound/soc/codecs/ just like it is the case for HDAudio. Either that or at least a ASoC-component representative, a dependency for UAOL-capable card to enumerate.
>>
> 
> Just to clarify, "struct snd_soc_usb" does have some correlation with our "codec" entity within the QCOM ASoC design.  This would be the q6usb driver.
> 
> 
>> Currently struct snd_soc_usb does not represent any component at all. Lack of codec representative, component representative and, given my current understanding, mixed dependency of sound/usb on sound/soc/soc-usb does lead to hard-to-understand ASoC solution.
> 
> 
> IMO the dependency on USB SND is necessary, so that we can leverage all the pre-existing sequences used to identify USB audio devices, and have some ability to utilize USB HCD APIs as well within the offload driver.

So, while I do not have patches in shape good enough to be shared, what 
we have in mind is closer to existing HDAudio solution and how it is 
covered in both ALSA and ASoC.

A ASoC sound card is effectively a combination of instances of struct 
snd_soc_component. Think of it as an MFD device. Typically at least two 
components are needed:

- platform component, e.g.: for representing DSP-capable device
- codec component, e.g.: for representing the codec device

USB could be represented by such a component, listed as a dependency of 
a sound card. By component I literally mean it extending the base struct:

stuct snd_soc_usb {
	struct snd_soc_component base;
	(...)
};

In my opinion HDAudio is a good example of how to mesh existing 
ALSA-based implementation with ASoC. Full, well implemented behaviour of 
HDAudio codec device drivers is present at sound/pci/hda/patch_*.c and 
friends. That part of devoid of any ASoC members. At the same time, an 
ASoC wrapper is present at sound/soc/codecs/hda.c. It will represent 
each and every HDAudio codec device on the HDAudio bus as a 
ASoC-component. This follows the ASoC design and thus is easy understand 
for any daily ASoC user, at least in my opinion.

Next, the USB Audio Offload streams are a limited resource but I do not 
see a reason to not treat it as a pool. Again, HDAudio comes into 
picture. The HDAudio streams are assigned and released with help of 
HDAudio library, code found in sound/hda/hdac_stream.c. In essence, as 
long as UAOL-capable streaming is allowed, a pcm->open() could approach 
a UAOL-lib (? component perhaps?) and perform ->assign(). If no 
resources available, fallback to the non-offloaded case.

While I have not commented on the kcontrol part, the above means that 
our current design does go into a different direction. We'd like to 
avoid stream-assignment hardcoding i.e.: predefining who owns a 
UAOL-capable stream if possible.

Kind regards,
Czarek