PDA

View Full Version : Multichannel Audio Specification



mailrsharma
01-28-2011, 10:26 AM
as of today there is no multichannel audio specification in the OpenMax IL 1.1.2 standard. :(
I would like to have suggestion about doing following things in a multichannel decoder
e.g.
1> how to configure an audio decoder for a required speaker layout.
i.e. to tell the decoder about expected output channels
2> how to enable the downmix algo present inside the decoder e.g. DTS & Dolby has there own downmixing algo.
3> how to configure an audio decoder for discarding LFE channel or downmixing it to front channels
4> how to configure decoder downmix algo for expected channel output
this is similar to first point.
5> how to configure an audio decoder for desired output pcm bits (16 / 24 / 32 (!) )

so far only mono/stereo decoders were there and it was quite easy for integrator.
but when multichannel decoders comes into play, there will be lot of requirements in terms of expected output.

i.e. some particular configuration at HDMI out
or stereo output at speakers or something else

integrator and component developer will be shuffling mails for months.

I think there can be a single structure, e.g. OMX_AUDIO_MULTICHANNELCONFIG , for giving all these parameters at the input port of the multichannel decoders to instruct the decoder about expected output and hence making it easier for integrator :)

mgao
01-28-2011, 10:53 PM
as of today there is no multichannel audio specification in the OpenMax IL 1.1.2 standard. :(
There is.

I would like to have suggestion about doing following things in a multichannel decoder
e.g.
1> how to configure an audio decoder for a required speaker layout.
i.e. to tell the decoder about expected output channels
2> how to enable the downmix algo present inside the decoder e.g. DTS & Dolby has there own downmixing algo.
3> how to configure an audio decoder for discarding LFE channel or downmixing it to front channels
4> how to configure decoder downmix algo for expected channel output
this is similar to first point.
5> how to configure an audio decoder for desired output pcm bits (16 / 24 / 32 (!) )

All of the above is available through output port OMX_AUDIO_PARAM_PCMMODETYPE.

mailrsharma
01-29-2011, 09:21 PM
"there is"

currently no multichannel decoder is there in standard and hence nothing has been written about handling these type of streams or requirements.

"All of the above is available through output port OMX_AUDIO_PARAM_PCMMODETYPE"

How can we do following work using this structure
2> how to enable the downmix algo present inside the decoder
3> how to configure an audio decoder for discarding LFE channel or downmixing it to front channels

Moreover for doing
1> how to configure an audio decoder for a required speaker layout.

I suppose you are refering to following array in the structure

OMX_AUDIO_CHANNELTYPE eChannelMapping[OMX_AUDIO_MAXCHANNELS];

I understand one can do setparameter on this structure and that client has full read & write access to this structure. therefore this structure can be used.

but decoder components generally will read data from input port and configure the output pcm port accordingly. say we have 7.1 input stream at input port, then component will configure the pcm port for 8 channels out and other members accordingly.

but if integrator wants 4.0 downmix and again does setparameter on this port, there may be race condition on this port if setparameter implementation has been made asynchronous by developer.

Moreover when I read about the eChannelMapping[] explanation in standard,
it is written on page 148 that

"eChannelMapping is the audio channel mapping enumeration. A component
will indicate the order of the audio channels as shown in Table 4-4."

from this, I was expecting that this array should be used by decoder component to tell the client that which channels it has decoded

woun't it be good to have these parameters inside the multichannel decoder parameter structure, whenever they are introduced in standard e.g. DTS, Dolby, WMA-Pro, AAC MC etc. or if possible to have new independent structure to send all this information through Input port.

because it will be good if
Input Port sends all the information i.e. about stream & integrator expectation to the component and
Component sends decoded information to the Ouput port about what it has decoded.
may be it will be more easier to do this way

in any case I am not against using structure OMX_AUDIO_PARAM_PCMMODETYPE

We are also planning to use this structure only, as there is no other choice
may be you can say that, we don't need any.