linux-kernel - Re: [PATCH 2/2] kselftest/alsa: pcm-test: Decrease stream duration from 4 to 2 seconds

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]

Message-ID: <443f697b-fecf-6e8e-0b76-65257aff7da8@perex.cz>
Date:   Wed, 21 Jun 2023 16:08:47 +0200
From:   Jaroslav Kysela <perex@...ex.cz>
To:     Mark Brown <broonie@...nel.org>,
        Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>
Cc:     kernel@...labora.com,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Shuah Khan <shuah@...nel.org>, Takashi Iwai <tiwai@...e.com>,
        alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 2/2] kselftest/alsa: pcm-test: Decrease stream duration
 from 4 to 2 seconds

On 21. 06. 23 15:08, Mark Brown wrote:
> On Tue, Jun 20, 2023 at 06:08:26PM -0400, Nícolas F. R. A. Prado wrote:
> 
>> -	const int duration_s = 4, margin_ms = 100;
>> +	const int duration_s = 2, margin_ms = 100;
> 
> This doesn't scale the margin with the duration which will affect the
> sensitivity of the test to misclocking.  It should make it less
> sensitive which is *probably* safer but at least worth noting.
> 
> We might also have issues with some of the lower sample rates, IIRC some
> devices are constrained in ways that mean they want a minimum buffer
> size which is harder to satisfy with very short playbacks and low sample
> rates.
> 
> I don't know why Jaroslav picked the 4s number here.

You basically replied yourself. The values (time + margin) were picked to do 
the DMA test for a reasonable time - based on my experience.

I think that the problem is somewhere else here. The overall test timeout 
should be calculated dynamically. All tests may be queried for the maximal 
expected interval based on the hardware/software capabilities. It's a bit 
pitfall to have a fixed time limit where the realtime tests depend on the 
number of devices.

					Jaroslav

-- 
Jaroslav Kysela <perex@...ex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.