> On 12/10/2024 8:40 AM, Takashi Iwai wrote: >> On Tue, 10 Dec 2024 01:59:10 +0100, >> Wesley Cheng wrote: >>> On 12/5/2024 4:53 PM, Wesley Cheng wrote: >>> Hi Takashi, >>> >>> Could you possibly help share some direction on what you think of the current design, and if you think its detrimental that we make modifications mentioned by Cezary? I have the next revision ready for review, but I wanted to get a better sense on the likeliness of this landing upstream w/o the major modifications. >> >> Honestly speaking, I have no big preference about that design >> question. The most important thing is rather what's visible change to >> users. An advantage of the current design (sort of add-on to the >> existing USB-audio driver) is that it's merely a few card controls >> that are added and visible, and the rest is just as of now. The >> remaining design issue (two cards or single card) is rather >> kernel-internal, and has nothing to do with users. So I'm fine with >> the current design. >> >> OTOH, if we follow the pattern of HD-audio, at least there will be >> more preliminary changes in USB-audio driver side like we've done for >> HD-audio. That is, make most of USB-audio code to be usable as (a >> kind of) library code. It's more work, but certainly doable. And if >> that can be achieved and there other similar use cases of this stuff >> not only from Qualcomm, it might make sense to go in that way, too. >> That said, it's rather a question about what's extended in future. >> If Intel will need / want to move on that direction, too, that's a >> good reason to reconsider the basic design. >> > > So to clarify, what Cezary and I are proposing are actually two different concepts to achieve some sort of offloading for audio data. In my use case, we're trying to leverage as much of the USB SND implementation as possible, and only offloading the handling of audio transfers. Everything else is still handled by USB SND, hence the reason for it being an add-on since most of it stays the same. Unfortunately, I don't have any details about the full HW offload design, as public material on it is fairly minimal. So it would be difficult for me to rework my series to something I don't have a line of sight into. Personally (and as you can probably tell :)), I would prefer if we could do the refactoring in stages (if actually required), since I've been pushing this method for awhile now, and I'm not sure if I can take up that effort to do that on my next submission. At least from the QC perspective if we did move to the HDaudio-type implementation, I think I'd need to also > change up the ASoC design we have currently implemented as well, so it wouldn't be a trivial change. > > > Thanks > > Wesley Cheng > Given that the series has already undergone extensive review, I prefer Wesley's design. We've begun leveraging the design in our local environment with positive results. Furthermore, we've proposed an additional feature to enable USB audio offload during system suspend [1]. In brief, by combining these two points, we can identify use cases where other vendors could also benefit from Wesley's design. [1] https://patchwork.kernel.org/project/linux-usb/cover/20241106083501.408074-1-guanyulin@xxxxxxxxxx/ Regards, Guan-Yu
