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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ