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. > 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.
Attachment:
signature.asc
Description: PGP signature
