linux-kernel - Re: [PATCH 1/3] ALSA: pcm: add support for 128kHz sample rate

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: Mon, 01 Jul 2024 16:07:49 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Amadeusz Sławiński
 <amadeuszx.slawinski@...ux.intel.com>
Cc: Jerome Brunet <jbrunet@...libre.com>,
	Mark Brown <broonie@...nel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Takashi Iwai <tiwai@...e.com>,
	Jaroslav Kysela <perex@...ex.cz>,
	alsa-devel@...a-project.org,
	linux-sound@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] ALSA: pcm: add support for 128kHz sample rate

On Mon, 01 Jul 2024 10:50:02 +0200,
Amadeusz Sławiński wrote:
> 
> On 6/28/2024 2:23 PM, Jerome Brunet wrote:
> > The usual sample rate possible on an SPDIF link are
> > 32k, 44.1k, 48k, 88.2k, 96k, 172.4k and 192k.
> > 
> > With higher bandwidth variant, such as eARC, and the introduction of 8
> > channels mode, the spdif frame rate may be multiplied by 4. This happens
> > when the interface use an IEC958_SUBFRAME format.
> > 
> > The spdif 8 channel mode rate list is:
> > 128k, 176.4k, 192k, 352.8k, 384k, 705.4k and 768k.
> > 
> > All are already supported by ASLA expect for the 128kHz one.
> > Add support for it but do not insert it the SNDRV_PCM_RATE_8000_192000
> > macro. Doing so would silently add 128k support to a lot of HW which
> > probably do not support it.
> > 
> > Signed-off-by: Jerome Brunet <jbrunet@...libre.com>
> > ---
> 
> From what I remember the recommendation is to not add new rates, but
> use SNDRV_PCM_RATE_KNOT for all rates not included already.

In general yes -- unless the new rate is used for significant amount
of drivers.

So this case is a sort of on a border line; if it's only for ASoC
SPDIF codec driver, I'd rather implement with an extra rate list
instead of extending the common bits (that has some potential risks by
breaking the existing numbers).  OTOH, if we can take this for further
cleanups of the existing requirement of 128khz rate, we can go with
it.


thanks,

Takashi