linux-kernel - Re: [alsa-devel] Question on Compressed offload session

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: <54662DC6.7070302@linux.intel.com>
Date:	Fri, 14 Nov 2014 10:28:54 -0600
From:	Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:	gsantosh@...eaurora.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>,
	Stephen Warren <swarren@...dotorg.org>,
	Linux-sh list <linux-sh@...r.kernel.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, alsa-devel-bounces@...a-project.org,
	Kuninori Morimoto <kuninori.morimoto.gx@...il.com>
Subject: Re: [alsa-devel] Question on Compressed offload session

On 11/13/14, 10:08 PM, gsantosh@...eaurora.org wrote:
>> 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
>>
>
> I Agree we cannot have a direct link between physical output  / input with
> decoder / encoder, during compressed playback.
> My concern here is, if we have a legacy codec driver which is used for the
> PCM out, and in the start up of this codec driver it is adding
> hw_constraints list, now the same codec driver is used for the compressed
> session FE or PCM session FE,
> If the routing is such that compressed FE -> codec the hw_constraints
> added by this driver is not valid here,
> and legacy drivers needs to be changed,
> Now the question comes how to change this drivers?
> I can think of following things
> if the routing is done for Compressed FE -> codec
>
> 1) in Codec driver avoid adding hw_constraint during startup if compressed
> session is routed, this recommend for codec driver to know that compress
> session is routed to codec which I feel not the correct way to handle this
>
> I was checking how to handle this situation in much better way.

What exactly do you call a 'legacy codec'? If there is a DAI i am not 
sure I understand the problem.

--
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/