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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA+D8ANg7C7vuxU44mAG8EnmcZjB_te5N_=4M4v_-Q9ZyPZ49g@mail.gmail.com>
Date: Mon, 12 Aug 2024 18:24:11 +0800
From: Shengjiu Wang <shengjiu.wang@...il.com>
To: Jaroslav Kysela <perex@...ex.cz>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>, 
	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 Fri, Aug 9, 2024 at 10:01 PM Jaroslav Kysela <perex@...ex.cz> wrote:
>
> 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.

Thanks.

But the ASRC driver I implemented is different, I just register one sound
card, one device/subdevice.  but the ASRC hardware support 4 instances
together, so user can open the card device 4 times to create 4 instances
then the controls can only bind with compress streams.

I think I can remove the 'SNDRV_COMPRESS_SRC_RATIO_MOD',
Only define a private type for driver,  which means only the ASRC driver
and its user application know the type.

For the change in 'include/uapi/sound/compress_params.h",  should I
keep them,  is there any other suggestion for them?

Best regards
Shengjiu Wang

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