linux-kernel - Re: [RFC PATCH v2 4/6] ASoC: fsl_asrc_m2m: Add memory to memory function

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: <eceafeef-2dba-48aa-b8b3-198b9bb39fb6@perex.cz>
Date: Tue, 20 Aug 2024 09:42:39 +0200
From: Jaroslav Kysela <perex@...ex.cz>
To: Shengjiu Wang <shengjiu.wang@...il.com>,
 Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.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 v2 4/6] ASoC: fsl_asrc_m2m: Add memory to memory
 function

On 20. 08. 24 9:37, Shengjiu Wang wrote:
> On Tue, Aug 20, 2024 at 2:59 PM Pierre-Louis Bossart
> <pierre-louis.bossart@...ux.intel.com> wrote:
>>
>>
>>
>> On 8/20/24 04:53, Shengjiu Wang wrote:
>>> On Mon, Aug 19, 2024 at 3:42 PM Pierre-Louis Bossart
>>> <pierre-louis.bossart@...ux.intel.com> wrote:
>>>>
>>>>
>>>>
>>>> On 8/16/24 12:42, Shengjiu Wang wrote:
>>>>> Implement the ASRC memory to memory function using
>>>>> the compress framework, user can use this function with
>>>>> compress ioctl interface.
>>>>>
>>>>> Define below private metadata key value for output
>>>>> format, output rate and ratio modifier configuration.
>>>>> ASRC_OUTPUT_FORMAT 0x80000001
>>>>> ASRC_OUTPUT_RATE   0x80000002
>>>>> ASRC_RATIO_MOD     0x80000003
>>>>
>>>> Can the output format/rate change at run-time?
>>>
>>> Seldom I think.
>>>
>>>>
>>>> If no, then these parameters should be moved somewhere else - e.g.
>>>> hw_params or something.
>>>
>>> This means I will do some changes in compress_params.h, add
>>> output format and output rate definition, follow Jaroslav's example
>>> right?
>>
>> yes, having parameters for the PCM case would make sense.
>>
>>>> I am still not very clear on the expanding the SET_METADATA ioctl to
>>>> deal with the ratio changes. This isn't linked to the control layer as
>>>> suggested before, and there's no precedent of calling it multiple times
>>>> during streaming.
>>>
>>> Which control layer? if you means the snd_kcontrol_new?  it is bound
>>> with sound card,  but in my case,  I need to the control bind with
>>> the snd_compr_stream to support multi streams/instances.
>>
>> I can only quote Jaroslav's previous answer:
>>
>> "
>> This argument is not valid. The controls are bound to the card, but the
>> element identifiers have already iface (interface), device and subdevice
>> numbers. We are using controls for PCM devices for example. The binding
>> is straight.
>>
>> Just add SNDRV_CTL_ELEM_IFACE_COMPRESS define and specify the compress
>> device number in the 'struct snd_ctl_elem_id'.
>> "
> 
> I don't think it is doable,  or at least I don't know how to do it.
> 
> My case is just one card/one device/one subdevice.  can't use it to
> distinguish multi streams.

I already wrote that the compress core code should be extended to support 
subdevices like other ALSA APIs. I'll work on it. For now, just add support 
for one converter.

					Jaroslav

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