Setting the audio output device

The RPi has two audio outputs: HDMI and 3.5mm analog. At the ALSA level you can choose between them by

amixer cset numid=3 <n>

where n is 0=auto, 1=headphones, 2=hdmi (http://elinux.org/R-Pi_Troubleshooting).

At the OpenMAX programming level you can choose between them using the Broadcom OpenMAX extension type OMX_CONFIG_BRCMAUDIOSOURCETYPE

OMX_SetParameter(handle, OMX_IndexConfigBrcmAudioDestination, &arDest)

where arDest.sName can be either "local" or "hdmi". (This is in the hello_audio example.)

When I plug in a USB sound card ALSA can see it as device hw:1 (card 1). I can play to it using
aplay -D hw:1,0 ...
and even set it as the default audio out by adding this to /etc/asound.conf

pcm.!default {
type hw;
card 1;
}

But how I do I tell OpenMAX to use this as the output device? It still plays to the original devices even if I have reset the ALSA default. Is there some alternative string I should use besides "local" and "hdmi"? If so, how do I figure out what that string is?

The OMX.broadcom.audio_render component provides access to the *Broadcom* hardware. To use ALSA (linux api) requires the use of an OpenMax ALSA audio sink component such as provided in Bellagio
http://sourceforge.net/projects/omxil/

Thanks OtherCrashOverride!

I was under the impression that the Broadcom OpenMAX IL used ALSA but I now see that is wrong. I checked with "ldd" on an OpenMAX executable using Broadcom audio_render and there is no link to libasound which would be needed if ALSA was used. So using USB audio cards (which only have ALSA drivers) with the current Broadcom components seems to be out of the picture, either for playback or recording.

I'm intrigued by your suggestion to use the Bellagio OpenMAX components. Can I use them with the Broadcom core? The Bellagio core uses a file ~/.omxregister which contains a list of components which point to .so files in /usr/local/lib/bellagio/ but I haven't been able to find any equivalent in Broadcom. I would not have thought it likely that Bellagio components would work with the Broadcom core anyway - the Bellagio components have to implement a function omx_component_library_Setup while Broadcom seems to have other interesting functions to create components.

I guess I could just use the Bellagio components and core, but that would lose the advantages of being able to integrate with video that uses the Broadcom core and the GPU.

It is possible to chain OpenMax libraries together as is done here http://limoa.sourceforge.net/docs/1.0/group__core__loader.html

Also, LIM OpenMAX IL core can serve as the super IL core where components from other IL cores can be dynamically loaded and universally enumerated.

I have proposed using this concept for Raspberry PI here http://www.raspberrypi.org/phpBB3/viewtopic.php?f=70&t=32601.

@OtherCrashOverride ,

Are you sure that this can actually be done on the Pi though? My understanding was that the Pi's openmax implementation was on the GPU, with just a thin wrapper running on the ARM to pass messages and data between the ARM and the GPU. I can't see how you can integrate ARM-based openmax components with GPU-based ones.

But I hope I'm wrong - it would be nice to be able to extend the Pi's openmax implementation with ARM code.

Are you sure that this can actually be done on the Pi though?

Although I am sure, this is why a proof-of-concept is needed.

I can't see how you can integrate ARM-based openmax components with GPU-based ones.

The integration occurs through the use of buffers. How a component does what it does is not important (black box) as long as its empties and fills buffers in a conformant manner. Components with intimate knowledge of each other can negotiate proprietary data exchange but they must all have basic buffer usage to be compliant.

It is possible to chain OpenMax libraries together as is done here http://limoa.sourceforge.net/docs/1.0/group__core__loader.html

Also, LIM OpenMAX IL core can serve as the super IL core where components from other IL cores can be dynamically loaded and universally enumerated.

Those would be cool to play with. Alas (and a bit off topic) the LIM downloads are broken since they use a repo android.git.kernel.org that doesn't seem to exist any more. I've logged bugs but no response so far. Anyone know where to get a copy of LIM OpenMAX?

The Android repo tool is broken for me too. The source code can be found here http://limoa.git.sourceforge.net/git/gitweb-index.cgi and can be manually cloned. You have to copy the root.mk in build.git to a top level folder containing all the code and rename it Makefile. The root.readme file has build instructions.

I have managed to build it on Pi and its not a trivial or quick endeavor. During the build a copy of the ffmpeg repository is checked out, rolled back, and patched (see my comments in the other thread about "Why libav/ffmpeg Is Not The Answer"). If you are missing any dependencies, the entire build process must be restarted and it does take HOURS to compile even with distcc.

The code also has to be patched to get it to load the PI openmax.so since it expects to find component roles which PI does not provide. Perhaps this should be filed as a bug report on the PI userland repository.

I have gotten it to load both its own components and the PI openmax components and I am able to use the PI openmax layer through it. However, there appear to be issues with the lim openmax codebase. It sometimes crashes at start up for me. Additionaly, the sample player it includes does not function properly. I suspect it is some kind of struct packing issue with the compiler adding filler bytes for type alignment. The OMX_BUFFERHEADER type length is reported as 80 bytes by lim and as 72 bytes by PI.

Thanks OtherCrashOverride, got it.

Code: Select all

git clone git://limoa.git.sourceforge.net/gitroot/limoa/limoi-components
git clone git://limoa.git.sourceforge.net/gitroot/limoa/limoi-core
git clone git://limoa.git.sourceforge.net/gitroot/limoa/limoi-plugins
git clone git://limoa.git.sourceforge.net/gitroot/limoa/limutil
git clone git://limoa.git.sourceforge.net/gitroot/limoa/manifest

Your build instructions look fine, building now on my Fedora box, just a few hiccups so far . I'll try the Rpi afterwards