Re: [RFC 00/15] ALSA/ASoC: USB Audio Offload

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

>>> In regard to the HDAudio point, I see clear benefits by having HDAudio and USB aligned in the approach on ASoC side. It's a path that's known, works and is well tested.
>>
>> The current direction for HDaudio is to have the DSP handle ALL streams with DSP-enabled drivers (or none with snd-hda-intel).
>>
>> But for USB we absolutely need the ability to bypass the DSP when the resources are exceeded (too many endpoints, too many channels, etc), or when low-latency is required (lowering CPU utilization comes at the expense of latency).
>>
>> In other words, the USB solution MUST expose two PCM paths, a legacy one and a DSP-one, and a sideband communication between DSP and legacy drivers to manage resources.
>>
>> HDAudio has none of those concepts, which makes it hard to see what the suggested alignment is?
> 
> 
> Hi Pierre,
> 
> I see your point but the spec describes the exact opposite. The intention is to follow the Intel's software architecture specification for USB Audio Offload Link (UAOL). The high-level steps provided in previous replies align with the recommendations of the spec. The reservation of Audio Sideband resources and negotiation of audio format are part of that. There is no intention to offload every single USB device and the device is to be claimed for offload entirely or fallback to the classic, offload-unaware driver.
> 
> That design (UAOL) is known, well tested and proven on the market. It shares a number of logical flows with the HDAudio case and thus having similar programming on the software side both makes the code easier to understand and aligns with the spec's recommendations.

I don't know what specification you are referring to... We've consistently agreed with others that the use of the offload capability was a run-time decision left as an exercise for the application. The low-level details of the UAOL flows and IPC should not define how USB is used, they are a 'detail' that should be well compartmentalized in Intel-specific host configurations.

The main argument I would have to keep the legacy non-offload solution always available is that USB is the only solution for users if for some reason their DSP-based solution is not supported (missing or incomplete machine driver, missing firmware, etc). Forcing users to rely on offload is not a good direction, it has to opt-in for Linux distributions.

I should also point out that one key requirement is that the DSP-based solution does not degrade the quality with any asynchronous sample-rate converter, which requires firmware to be able to avoid working with the 1ms tick but instead adjust the amount of data processed per tick, specifically in the case of endpoints with feedback. If the firmware does resample with a TBD filter, then the performance of that TBD filter should be clearly documented. We had similar discussions in the past with MP3 offload, the expectation is that offload only improves power consumption but does not result in any quality shortcuts taken.