Em Tue, 30 Apr 2024 23:46:03 +0900 Mark Brown <broonie@xxxxxxxxxx> escreveu: > On Tue, Apr 30, 2024 at 10:21:12AM +0200, Sebastian Fricke wrote: > > > first of all thanks for all of this work and I am very sorry for only > > emerging this late into the series, I sadly didn't notice it earlier. > > It might be worth checking out the discussion on earlier versions... > > > 1. The biggest objection is, that the Linux Kernel has a subsystem > > specifically targeted for audio devices, adding support for these > > devices in another subsystem are counterproductive as they work around > > the shortcomings of the audio subsystem while forcing support for a > > device into a subsystem that was never designed for such devices. > > Instead, the audio subsystem has to be adjusted to be able to support > > all of the required workflows, otherwise, the next audio driver with > > similar requirements will have to move to the media subsystem as well, > > the audio subsystem would then never experience the required change and > > soon we would have two audio subsystems. > > The discussion around this originally was that all the audio APIs are > very much centered around real time operations rather than completely > async memory to memory operations and that it's not clear that it's > worth reinventing the wheel simply for the sake of having things in > ALSA when that's already pretty idiomatic for the media subsystem. It > wasn't the memory to memory bit per se, it was the disconnection from > any timing. The media subsystem is also centered around real time. Without real time, you can't have a decent video conference system. Having mem2mem transfers actually help reducing real time delays, as it avoids extra latency due to CPU congestion and/or data transfers from/to userspace. > > > So instead of hammering a driver into the wrong destination, I would > > suggest bundling our forces and implementing a general memory-to-memory > > framework that both the media and the audio subsystem can use, that > > addresses the current shortcomings of the implementation and allows you > > to upload the driver where it is supposed to be. > > That doesn't sound like an immediate solution to maintainer overload > issues... if something like this is going to happen the DRM solution > does seem more general but I'm not sure the amount of stop energy is > proportionate. I don't think maintainer overload is the issue here. The main point is to avoid a fork at the audio uAPI, plus the burden of re-inventing the wheel with new codes for audio formats, new documentation for them, etc. Regards, Mauro
