[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA+D8AMOr8=JS7A0DvOEatL79CwwT4De7vDs6H-VDi05AnkjHQ@mail.gmail.com>
Date: Tue, 20 Aug 2024 15:52:20 +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 v2 4/6] ASoC: fsl_asrc_m2m: Add memory to memory function
On Tue, Aug 20, 2024 at 3:42 PM Jaroslav Kysela <perex@...ex.cz> wrote:
>
> 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.
Thanks.
What does this subdevices mean? Is it equal to the compress streams?
When I call snd_compr_ops.open(), it means to create an instance, the instance
is created at runtime (call open()), not created when the sound card is created.
Best regards
Shengjiu Wang
>
> Jaroslav
>
> --
> Jaroslav Kysela <perex@...ex.cz>
> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
>
Powered by blists - more mailing lists