linux-kernel - Re: [RFC PATCH 1/6] ALSA: compress: add Sample Rate Converter codec support

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: <c3b8f7b8-fc5e-4285-bee8-7edd448a405d@perex.cz>
Date: Fri, 9 Aug 2024 16:00:58 +0200
From: Jaroslav Kysela <perex@...ex.cz>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
 Shengjiu Wang <shengjiu.wang@...il.com>
Cc: Shengjiu Wang <shengjiu.wang@....com>, vkoul@...nel.org, tiwai@...e.com,
 alsa-devel@...a-project.org, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org, Xiubo.Lee@...il.com, festevam@...il.com,
 nicoleotsuka@...il.com, lgirdwood@...il.com, broonie@...nel.org,
 linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH 1/6] ALSA: compress: add Sample Rate Converter codec
 support

On 09. 08. 24 14:52, Pierre-Louis Bossart wrote:

>> And metadata
>> ioctl can be called many times which can meet the ratio modifier
>> requirement (ratio may be drift on the fly)
> 
> Interesting, that's yet another way of handling the drift with userspace
> modifying the ratio dynamically. That's different to what I've seen before.

Note that the "timing" is managed by the user space with this scheme.

>> And compress API uses codec as the unit for capability query and
>> parameter setting,  So I think need to define "SND_AUDIOCODEC_SRC'
>> and 'struct snd_dec_src',  for the 'snd_dec_src' just defined output
>> format and output rate, channels definition just reuse the snd_codec.ch_in.
> 
> The capability query is an interesting point as well, it's not clear how
> to expose to userspace what this specific implementation can do, while
> at the same time *requiring* userpace to update the ratio dynamically.
> For something like this to work, userspace needs to have pre-existing
> information on how the SRC works.

Yes, it's about abstraction. The user space wants to push data, read data back 
converted to the target rate and eventually modify the drift using a control 
managing clocks using own way. We can eventually assume, that if this control 
does not exist, the drift cannot be controlled. Also, nice thing is that the 
control has min and max values (range), so driver can specify the drift range, 
too.

And again, look to "PCM Rate Shift 100000" control implementation in 
sound/drivers/aloop.c. It would be nice to have the base offset for the 
shift/drift/pitch value standardized.

					Jaroslav

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