At the moment BSPs are configured to choose as default audio output the HDMI if it's present. So if we have a NUC, for example, that has HDMI and audio jack then the audio jack cannot be used. There should be a method to choose the default output for audio playback maybe even in the graphical interface.
This is not the first case where QA has needed to manually modify the audio setup to be able to test things: I suggested that we consider adding a tool so they could do it easier. There do not seem to be (easy) command line tools for controlling pulseaudio, but pavucontrol is not too big. It does depend on gtkmm though...
We can also consider the command line tool - pacmd for this purpose.
pacmd is provided by "pulseaudio-misc" package: ie: in local.conf: IMAGE_INSTALL_append = " pulseaudio-misc"
Prepared an image with "pulseaudio-misc" for pacmd and "alsa-utils-aplay" for aplay. ie: IMAGE_INSTALL_append =" pulseaudio-misc alsa-utils-aplay" After booting the device, listed the available devices using aplay: root@genericx86-64:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 Verified the output by playing a wave file using aplay: # aplay -D hw:1,0 test.wav (sound on headset) # aplay -D hw:0,3 test.wav (sound on HDMI) Listed the available sinks using pacmd: root@genericx86-64:~# pacmd list-sinks|grep index * index: 0 index: 1 root@genericx86-64:~# pacmd list-sinks |grep name name: <alsa_output.pci-0000_00_03.0.hdmi-stereo> alsa.name = "HDMI 0" alsa.subdevice_name = "subdevice #0" alsa.card_name = "HDA Intel HDMI" alsa.long_card_name = "HDA Intel HDMI at 0xf7134000 irq 45" alsa.driver_name = "snd_hda_intel" device.profile.name = "hdmi-stereo" alsa.mixer_name = "Intel Broadwell HDMI" device.icon_name = "audio-card-pci" device.icon_name = "video-display" device.product.name = "W2261" name: <alsa_output.pci-0000_00_1b.0.analog-stereo> alsa.name = "ALC283 Analog" alsa.subdevice_name = "subdevice #0" alsa.card_name = "HDA Intel PCH" alsa.long_card_name = "HDA Intel PCH at 0xf7130000 irq 44" alsa.driver_name = "snd_hda_intel" device.profile.name = "analog-stereo" alsa.mixer_name = "Realtek ALC283" device.icon_name = "audio-card-pci" device.icon_name = "audio-headphones" As we run the commands as "root", pacmd fails to spawn pulseaudio. We can temporarily test switching sound between devices using this script: root@genericx86-64:~# cat test.sh #!/bin/sh pulseaudio & pacmd set-default-sink 1 aplay test.wav pacmd set-default-sink 0 aplay test.wav
It seems that the indexes keep changing so before run the script it is necessary to verify the number of them by giving the command "pacmd list-sinks". Also add a sleep state in the script after "pulseaudio &" if it does not start immediately.
The workaround works. Also I was able to play sound on HDMI by putting this line: load-module module-alsa-sink device=hw:0,3 in /etc/pulse/default.pa (John Maxin idea)
If we plan to bring "pavucontrol" from meta-oe to oe-core, we will have to move below listed recipes to oe-core as well. That means, a large number of new recipes for a UI application which configures pulseaudio (undesirable). new file: ../meta/recipes-core/glib-2.0/glibmm/remove-examples.patch new file: ../meta/recipes-core/glib-2.0/glibmm_2.44.0.bb new file: ../meta/recipes-core/libsigc++-2.0/libsigc++-2.0_2.2.11.bb new file: ../meta/recipes-core/mm-common/mm-common_0.9.8.bb new file: ../meta/recipes-gnome/atk/atkmm_2.22.7.bb new file: ../meta/recipes-gnome/gtk+/gtkmm_2.24.3.bb new file: ../meta/recipes-graphics/cairo/cairomm_1.11.2.bb new file: ../meta/recipes-graphics/pango/pangomm_2.36.0.bb new file: ../meta/recipes-multimedia/pulseaudio/pavucontrol_3.0.bb new file: ../meta/recipes-support/libcanberra/files/0001-build-gtk-and-gtk3-version-for-canberra_gtk_play.patch new file: ../meta/recipes-support/libcanberra/libcanberra_0.30.bb These changes are available in this branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=maxin/pavucontrol
That's *a lot* of extra deps. Is there something a bit less massive?
Searching an alternative for pavucontrol resulted in "qpaeq". However, that also seems to have a number of extra deps like PyQt4 and sip. May be enabling the command line tool (pacmd) could save us from adding new recipes to oe-core.
pacmd is probably a good starting point then!
patch sent to oe-core: http://lists.openembedded.org/pipermail/openembedded-core/2015-December/114597.html
Accepted upstream: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4b543f7405430a2ab452dbd334b4b0a430e1091c
Note that pactl is better than pacmd. pactl shouldn't have any issues with spawning the daemon as needed. Another thing: you can use the sink name instead of the index, if you want a stable identifier.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4b543f7405430a2ab452dbd334b4b0a430e1091c