[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240430172752.20ffcd56@sal.lan>
Date: Tue, 30 Apr 2024 17:27:52 +0100
From: Mauro Carvalho Chehab <mchehab@...nel.org>
To: Mark Brown <broonie@...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
Em Tue, 30 Apr 2024 23:46:03 +0900
Mark Brown <broonie@...nel.org> 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
Powered by blists - more mailing lists