linux-kernel - Re: [RFC PATCH v2 0/7] 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] [day] [month] [year] [list]

Message-ID: <fea0cb4a94ab9ba757f32ad5539d075089dc63e7.camel@ndufresne.ca>
Date:   Thu, 31 Aug 2023 16:41:46 -0400
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Takashi Iwai <tiwai@...e.de>,
        Shengjiu Wang <shengjiu.wang@...il.com>
Cc:     Mark Brown <broonie@...nel.org>, Hans Verkuil <hverkuil@...all.nl>,
        Shengjiu Wang <shengjiu.wang@....com>, sakari.ailus@....fi,
        tfiga@...omium.org, m.szyprowski@...sung.com, mchehab@...nel.org,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        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: [RFC PATCH v2 0/7] Add audio support in v4l2 framework

Hi,

Le jeudi 24 août 2023 à 19:03 +0200, Takashi Iwai a écrit :
> > 3. How to handle the xrun issue. pause or resume. which are brought by ALSA.
> 
> Doesn't V4L2 handle the overrun/underrun at all?  Also, no resume
> support?

just a 2 cents comment. All our video m2m are job based. When there is no job
available they stop and resume when there is more work in queues. As there is no
time constraints coming from the hardware, there is also no API to know that
there has been a period of time without anything being executed (under
utilization). Only overrun can be detected by application, each chunk of work is
in its own v4l2_buffer and the application will run out of buffer in that case,
and will have to wait for free space in the queue. Understand though that the
larger the queue, the large the latency. There is currently no way to submit job
ahead of the data (unlike DRM subsystem).

I have slight impression that all this seems rather inefficient for high rate /
small buffer. I'd suggest creating a dummy benchmark driver to verify that the
overhead isn't just too much for an audio use case.

Nicolas