On Tue, Apr 30, 2024 at 05:27:52PM +0100, Mauro Carvalho Chehab wrote: > Mark Brown <broonie@xxxxxxxxxx> escreveu: > > On Tue, Apr 30, 2024 at 10:21:12AM +0200, Sebastian Fricke wrote: > > The discussion around this originally was that all the audio APIs are > > very much centered around real time operations rather than completely > 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. Real time means strongly tied to wall clock times rather than fast - the issue was that all the ALSA APIs are based around pushing data through the system based on a clock. > > 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. I thought that discussion had been had already at one of the earlier versions? TBH I've not really been paying attention to this since the very early versions where I raised some similar "why is this in media" points and I thought everyone had decided that this did actually make sense.
Attachment:
signature.asc
Description: PGP signature
