codec_adapter: prepare for dynamic codec id #4572
Conversation
Potochi
requested review from
dbaluta,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
|
Can one of the admins verify this patch?
|
|
test this please |
| /* req_api_id will be passed via parameters from the linux | ||
| * kernel and it will contain the api_id of the file format. | ||
| */ | ||
| uint32_t req_api_id = CADENCE_CODEC_MP3_DEC_ID; |
There was a problem hiding this comment.
Is this some sort of default?
There was a problem hiding this comment.
As mentioned in the commit message, we use this as default for now because codec id should be sent from the kernel side. Why don't have a clean way to do that now.
|
@mrajwa that sounds good. As far as I remember we do not support passthrough with Cadence libraries. Should we create a dummy library which exposes a function that just copies input to output? |
|
@dbaluta by passthrough I mean no lib was selected at all here so we just copy in -> out. I don't get why Mp3 codec (or any other) should be assumed as the default one if none was specified. |
|
@mrajwa i understood you from your first comment. But we still need to plugin this passthrough functionality in the codec_adapter framework. We need to understand at what level we implement the passthrough:
Notice that we have UUID that identifies the library type (e.g Dolby, Cadence) and then we also have codec id inside Cadence which identifies which particular API / library for Cadence is used. Indeed you are right, we didn't took into cosnsideration the passthrough case so for this reason we considered MP3 as default case. |
For now the codec id is determined from the topology file, this doesn't scale well when we have to support a lot of codecs. The earlyest time when we can get the codec id is in "cadence_codec_prepare". So we move some of the codec initialisation from "cadence_codec_init" into "cadence_codec_prepare". The current topologies which specify the codec id directly will still work, new topologies that want to use this functionality must specify "0" as the codec id. The codec id should be sent by the linux kernel. Until this will happen we assume the default codec id to be for MP3. Signed-off-by: Bud Liviu-Alexandru <budliviu@gmail.com>
|
@mrajwa we had a deeper look at this and your comment suggests that we should implement the passthrough functionality using the Cadence API, this is not really what we intended with this commit. Maybe we can leave this for later. Why, I'm advocating for using an already implemented codec ID for now is that actually that values shouldn't matter once we send the parameters from kernel side. We don't have yet a field for codec_id inside parameters structure passed from the kernel. We can eventually go with a default like: what do you say? |
|
@mrajwa ping - need your inputs. |
|
@dbaluta if the codec selection is not complete in any way we should set the adapter to pass thru mode where we only copy input to output. I would not make any assumption about unspecified codec id. Sorry for late responses I am on vacations currently. |
|
@mrajwa lets move this to v1.10 milestone, as there are a lot of things needed to be discussed. Including Kernel side changes. |
|
@dbaluta ping ? |
|
@lgirdwood thanks for reminder. we were busy with some bugfixing. will send this week a follow up to this patch. |
|
Replaced with #5245 |
For now the codec id is determined from the topology file, this
doesn't scale well when we have to support a lot of codecs.
The earlyest time when we can get the codec id is in
"cadence_codec_prepare". So we move some of the codec initialisation
from "cadence_codec_init" into "cadence_codec_prepare".
The current topologies which specify the codec id directly will still
work, new topologies that want to use this functionality must specify
"0" as the codec id.
The codec id should be sent by the linux kernel. Until this will happen
we assume the default codec id to be for MP3.
Signed-off-by: Bud Liviu-Alexandru budliviu@gmail.com