linux-kernel - Re: [PATCH v15 00/16] Add audio support in v4l2 framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 1 May 2024 10:56:15 +0900
From: Mark Brown <broonie@...nel.org>
To: Mauro Carvalho Chehab <mchehab@...nel.org>
Cc: Sebastian Fricke <sebastian.fricke@...labora.com>,
	Shengjiu Wang <shengjiu.wang@....com>, hverkuil@...all.nl,
	sakari.ailus@....fi, tfiga@...omium.org, m.szyprowski@...sung.com,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	shengjiu.wang@...il.com, Xiubo.Lee@...il.com, festevam@...il.com,
	nicoleotsuka@...il.com, lgirdwood@...il.com, perex@...ex.cz,
	tiwai@...e.com, alsa-devel@...a-project.org,
	linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v15 00/16] Add audio support in v4l2 framework

On Tue, Apr 30, 2024 at 05:27:52PM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown <broonie@...nel.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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)