(This is still quite exploratory: when some of the questions have been answered and we find out if our suppositions are right, we can build a configuration option to enable audio cleanly)
To enable the audio subsystem, you first need to write to /dev/subsys_adsp
# echo 1 > /dev/subsys_adsp bash: echo: write error: Invalid argument
which results in a lot of kernel messages from msm8952-asoc-wcd and
msm-pcm-routing (including a lot of "Failed to add route" which
seem to be harmless and are also emitted under Android)
Then you need to configure the mixer. Phone audio is complicated due to many input devices, many output devices (headphones, speaker, bluetooth, VoIP etc)and many different use cases - do you want high-quality audio for streaming music, or low-latency audio for conversation or system alerts?
In Android the audio configuration is described in a file called
mixer_paths.xml, which you can probably pull from your handset
at /system/vendor/etc/mixer_paths.xml. The structure is as follows:
- mixer
- ctl
- path
- ctlIn this file, the "base" configuration is described by the ctl
elements which are direct children of mixer, and then each "use
case" is decribed by a path element which contains more ctl elements.
I used xmlstarlet to extract the configuration and generate amixer
command lines to replicate it in Linux. First we need the base
configuration -
xml sel -t -m '//mixer/ctl' -o "amixer -Ddefault cset 'name=\"" -v '@name' -o "\",index=" -v @id -o "' " -v '@value' -n mixer_paths.xml
and then to get any audible output I also chose the paths for "deep-buffer-playback" and "speaker"
xml sel -t -m '//mixer/path[@name="speaker" or @name="deep-buffer-playback"]/ctl' -o "amixer -Ddefault cset 'name=\"" -v '@name' -o "\",index=" -v @id -o "' " -v '@value' -n mixer_paths.xml
A lot of these amixer commands will print errors. I don’t know if this is harmless but it’s to be expected.
Given this setup I can play WAV files with aplay
aplay -Ddefault /root/countdown.wav
Clearly there is a lot left to do