Error when using OMX audio_render for ddp/dts passtrough on HDMI

[adn770]

I'm also working on audio pass trough scenarios but by using OpenMax in GStreamer [1].

I've already got a working sink for PCM raw audio with the information at [2] but with the the audio passtrough scenario I get an error in the attempt to allocate the buffers in the input port of audio_render.

audio_render got error: Insufficient resources (0x80001000)

Please could you give us some hint on what might be wrong ?

In order to reproduce the issue you can build with the following:

$ git clone https://github.com/metrological/buildroot
$ cd buildroot
$ make rpi_qt5webkit_defconfig
$ make

To deploy into an SD card with two partitions boot (fat32) and rootfs (ext4):
$ cp output/images/rpi-firmware/* /media//boot/
$ cp output/images/zImage /media/boot/
$ sudo tar xvf output/images/rootfs.tar -C /media/rootfs/

Download and copy some media with a dolby digital audio track, for example [3]

Once booted the rpi to reproduce the issue run the following GStreamer pipeline:

GST_DEBUG=omx*:4 gst-launch-1.0 filesrc location=/root/h264_720p_hp_5.1_6mbps_ac3_planet.mp4 ! qtdemux ! ac3parse ! queue ! omxhdmiaudiosink

[1] http://cgit.freedesktop.org/~adn770/gst-omx/log/?h=audiosink
[2] http://home.nouwen.name/RaspberryPi/documentation/ilcomponents/audio_render.html
[3] http://www.auby.no/files/video_tests/h264_720p_hp_5.1_6mbps_ac3_planet.mp4

[julianscheel]

@AD-N770 Could you add a link to the code that actually hits this error?
My first guess would be that you allocate too many or too few buffers on one of the involved ports. OMX can be really picky there.

[adn770]

@julianscheel sure, here it is http://cgit.freedesktop.org/~adn770/gst-omx/tree/omx/gstomxaudiosink.c?h=audiosink#n716

btw: are you around on IRC? me at #gstreamer

[popcornmix]

Are you submitting IEC 61937 formatted frames as OMX_AUDIO_CodingPCM data to audio_render?
Or are you submitting DTS/AC3 encoded frames as OMX_AUDIO_CodingDTS/OMX_AUDIO_CodingDDP?

[adn770]

@popcornmix I'm not yet at the point of submitting frames but I will be able to submit whatever it's needed.

Te actual plan was submit DTS/AC3 frames as OMX_AUDIO_CodingDTS/OMX_AUDIO_CodingDDP
but if it doesn't work I can payload to IEC 61937 (GStreamer already has infrastructure in place to achieve this in an easy manner) and submit as OMX_AUDIO_CodingPCM.

The issue is that I can't allocate buffers at input port when I configure it for OMX_AUDIO_CodingDTS/OMX_AUDIO_CodingDDP.

[popcornmix]

Submitting IEC 61937 to audio_render is in use by the Pi Sink in xbmc so is known to work.
Submitting DTS/AC3 frames to audio_decode tunnelled to audio_render is used by omxplayer and is known to work.
audio_decode does parse the headers of DTS/AC3 and fills in some out of band data used by audio_render.
Trying to pass DTS/AC3 straight to audio_render may or may not have issues, but AFAIK it's never been tried.

Sending IEC 61937 as PCM data to audio_render would be my suggestion.

[adn770]

Ok, I'll give a try on passing IEC 61937 as PCM data.

Please to avoid more issues could you describe what's the expected OMX_AUDIO_CodingPCM format [1] to pass IEC 61837 data ?

[1] http://cgit.freedesktop.org/~adn770/gst-omx/tree/omx/gstomxaudiosink.c?h=audiosink#n592

[popcornmix]

You want exactly the same settings as you use for 2 channel 16-bit PCM.

Some receivers require the number of channels in AV Infoframe to be set to 0.
Use "vcgencmd hdmi_stream_channels 1" before starting passthrough playback and "vcgencmd hdmi_stream_channels 0" before starting non-passthrough playback. (most receivers don't seem to care)

If audio_render is connected to a clock, then make sure audio is the clock master (i.e. don't set OMX_IndexConfigBrcmClockReferenceSource to false) as that allows audio to be resampled which is bad for passthrough.

Use this as a reference:
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkPi.cpp

[adn770]

I've got DD/DTS working with IEC61837 approach.

Thanks