Enable audio in chromium container

Can someone point me how to enable audio in Chromium container. I’ve managed to run chromium container after the weston container started. I also managed to exec in to my weston container and run aplay to play some sounds. However, when I want to play youtube video in chromium container I can’t get no sound (video streaming works). This are my starting scripts:


echo "Starting Weston container..."

docker run -d --rm --name=weston --net=host --cap-add CAP_SYS_TTY_CONFIG
-v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/
--device-cgroup-rule='c 4:* rmw' --device-cgroup-rule='c 13:* rmw'
--device-cgroup-rule='c 199:* rmw' --device-cgroup-rule='c 226:* rmw'     
--group-add audio
torizon/weston:2 --developer weston-launch --tty=/dev/tty7 --user=torizon

echo "Starting chromium container..."

docker run -d --rm --name=kiosk
-v /tmp:/tmp -v /var/run/dbus:/var/run/dbus
--security-opt seccomp=unconfined --shm-size 256mb   --group-add audio   
--virtual-keyboard www.youtube.com

What carrier board? I know you checked Verdin when applying tags, but it sounds like you might be using Dahlia.

The CODEC on the Dahlia has a lot of issues. To start with, if you are performing a straight EasyInstaller install of TorizonCore, the device drivers aren’t loaded. Only the device tree for the full sized Verdin carrier board is loaded.

You really need to build your own image and replace the device tree. See this message thread.

You really need to read the Errata and pull some resistors off, especially if you are going to think about having any sound input.

If you want non-static “good” sound coming in on the microphone there are other hardware modifications you will have to make and I’m not currently at liberty to share.

Once you jump through those hoops, you will find that there is a driver feature/bug/oddity where any WAV file you record will not be centered around zero. Your code will have to fix that. It helps if you copy the WAV files off to a Linux machine running Audacity so you can look a them.

Your first problem is that you don’t have the device tree loaded for your carrier board. You can verify this if you have a container with alsa-utils loaded. Just launch it interactively with a bash shell so you can tool around with aplay and arecord. Probably help if you copy some WAV files into your container while building as well.

Hey @seasoned_geek, I’m using Verdin development board, TorizonCore with PREEMPT_RT 5.3.0+build.7 EasyInstaller image and, as I said, managed to play some test sounds in Weston container, I used .wav provided in example, not that it matters .
I don’t think there is a problem with device tree or it’s a hardware issue. I think the problem is somewhere in my container run scripts.

I’ve managed to get my chromium container play both video and audio. I had to modify existing chromium Dockerfile and install libasound2 and alsa-utils:

ARG IMAGE_ARCH=linux/arm
# For arm64 use:
# ARG IMAGE_ARCH=linux/arm64

ARG BASE_IMAGE=wayland-base
# For iMX7 and iMX6ULL-emmc use:

# For iMX7 and iMX6ULL-emmc use:
# ARG IMAGE_TAG=2-bullseye


# Needs to come after FROM!
# For iMX7 and iMX6ULL-emmc use:

# If x11 build (iMX7 and iMX6ULL-emmc), use Chromium from Debian feed.
# Chromium-X11 is installed from the testing feed to get the latest version
# because version 99.0.4844.74-1~deb11u1 from stable feed is crashing.
RUN test "$BUILD_TYPE" = "x11" && \
        echo "deb http://deb.debian.org/debian testing main" >> /etc/apt/sources.list && \
        sed -i '/feeds.toradex.com/d' /etc/apt/sources.list || true

# Install Chromium
RUN apt-get -y update && \
    apt-get install libasound2 alsa-utils 

RUN apt-get -y update && \
    apt-get -o Acquire::Http::Dl-limit=100 install -y --no-install-recommends chromium chromium-sandbox && \
    apt-get clean && apt-get autoremove && \
    update-mime-database /usr/share/mime && \
    rm -rf /var/lib/apt/lists/*

# Unpack the virtual keyboard extension
ADD chrome-virtual-keyboard.tar.gz /chrome-extensions

COPY start-chromium.sh /usr/bin/start-browser

USER torizon


ENTRYPOINT ["/usr/bin/start-browser"]
# CMD ["http://www.toradex.com"]

Also I changed the chromium run script:


echo "Starting chromium container..."

docker run -d --rm --name=chromium     -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus     
--security-opt seccomp=unconfined      torizon/chromium:2     --virtual-keyboard     
--browser-mode     --virtual-keyboard www.youtube.com
1 Like


Well, your solution shouldn’t have worked. I will confess to not knowing what --security-opt does. “secomp=unconfined” sounds pretty dangerous.

Yes, libasound2 and alsa-utils are always good to add.

A container is like state-run media in a country run by a dictator. It only broadcasts what the dictator tells it.

When you issue the docker command you are the dictator. The Toradex documentation isn’t really good at explaining this. Maybe there is one page that makes total sense of everything, but after roughly six months of looking through all of the circular links, I have never found it.

docker run --rm -it --name=bamby 
# access to uarts
--device=/dev/verdin-uart1 --device=/dev/verdin-uart2 
# access to CODEC
# mount anything found in /media under /media/torizon owned by torizon
--mount type=bind,source=/media,target=/media/torizon,bind-propagation=shared  
# use the same tmp and dbus as the host
-v /tmp:/tmp -v /var/run/dbus:/var/run/dbus 
# stuff nobody understands but always includes
-v /dev/galcore:/dev/galcore --device-cgroup-rule='c 199:* rmw' 
# your container
# a bash shell for the interractive mode

When you mess with --privileged or --security-opt your container isn’t contained. It can now reach willy-nilly out into the host. Definitely something you do not want chromium to be able to do! Few things more insecure than a Web browser.

Just a couple of nits:

It seems that you have --virtual-keyboard listed twice.

Unless you mount some media anything the browser downloads won’t be accessible via the host. That may be what you want, I don’t know. Just passing the information along.

It took me a while to wrap my noggin around this as well.

A container must be viewed and treated like state-run media. It only gets what it gets, does what you tell it, and can be completely replaced at a moments notice.

The moment you give it any kind of --priv, it becomes “free press” and can do whatever it wants to the host.

The point of the container is to protect the host from both evil and reality.

Hi @spasoye,

Glad to see you were able to resolve your issue here. For your future reference we have a general article on audio inside a container: How to play audio on TorizonCore using Alsa and C/C++ | Toradex Developer Center

Best Regards,