[PATCH v15 00/16] Add audio support in v4l2 framework
Mark Brown
broonie at kernel.org
Wed May 1 11:56:15 AEST 2024
On Tue, Apr 30, 2024 at 05:27:52PM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown <broonie at kernel.org> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20240501/3bf162f4/attachment.sig>
More information about the Linuxppc-dev
mailing list