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: <874j99434a.wl-tiwai@suse.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ