[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5464CDE2.2070406@linux.intel.com>
Date: Thu, 13 Nov 2014 09:27:30 -0600
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: gsantosh@...eaurora.org, alsa-devel-bounces@...a-project.org
CC: Mark Rutland <mark.rutland@....com>, Rob Herring <robh@...nel.org>,
ALSA Development Mailing List <alsa-devel@...a-project.org>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
Linux-sh list <linux-sh@...r.kernel.org>,
Stephen Warren <swarren@...dotorg.org>,
Magnus <magnus.damm@...il.com>, linux-kernel@...r.kernel.org,
Olof Johansson <olof@...om.net>, devicetree@...r.kernel.org,
Mark Brown <broonie@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
grant.likely@...aro.org,
Kuninori Morimoto <kuninori.morimoto.gx@...il.com>
Subject: Re: [alsa-devel] Question on Compressed offload session
On 11/12/14, 9:02 PM, gsantosh@...eaurora.org wrote:
> Hi All,
>
> The Question is for the compressed offload session.
>
> For a generic codec driver during the startup function it will set some of
> the hw_constraints rule similarly like this.
>
> snd_pcm_hw_constraint_list(substream->runtime, 0,
> SNDRV_PCM_HW_PARAM_RATE,
> &constraints_12_24);
>
> pcm_lib.c will try to add the rule to the runtime structure by accessing
> the pointers which will be initialized during opening of the session,
> as The Constraints added by the codec driver will be updated in the
>
> struct snd_pcm_hw_constraints of runtime structure which will be part of
> substream handle.
>
> But for the compressed offload I do not see the initialization done for HW
> constraints, as done in pcm session
>
> 2092int snd_pcm_open_substream(struct snd_pcm *pcm, int stream,
> 2093 struct file *file,
> 2094 struct snd_pcm_substream **rsubstream)
>
> most of the existing drivers which has the hw_constraint_list code will
> not be applicable for compress offload session, how to solve this?
You can't directly link physical output/input with the decoder/encoder
in general.
For decoders, the sample-rate may not always be known ahead of time,
e.g. with AAC-SBR implicit signaling. There is no way to add constraints
on open, there is an assumption that a sample-rate converter is part of
the chain to take care of the difference between the output of the
offloaded decoder and the back-end actual sampling frequency (same with
number of channels and bit-width btw).
Likewise if you encode the frequency may not be the same as what the
backend provides and some SRC might be needed.
-Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists