Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not force sound card but fall back to ALSA config #150

Open
wants to merge 1 commit into
base: buster
Choose a base branch
from

Conversation

MichaIng
Copy link

@MichaIng MichaIng commented Dec 17, 2020

  • Description of what the PR does, such as fixes # {issue number}

Since a recent Raspberry Pi kernel upgrade, ALSA sound card 0 device 0 is pointing to HDMI sound, if a monitor is attached, while 3.5mm jack then is card 1 device 0. Previously both were at card 0 device 0, switchable via amixer control.

Forcing now card 0 device 0 hence forces HDMI audio (even if the monitor does not really support it) and hence breaks 3.5mm jack sound. To allow switching the sound device with usual methods (ALSA configuration or raspi-config on RPi), Mycroft must not force the exact sound device. If no custom ALSA configuration exists, card 0 device 0 is the default anyway.

Related issues:
https://community.mycroft.ai/t/picroft-no-sound-with-3-5mm-jack-output/9726
https://community.mycroft.ai/t/sound-always-go-through-hdmi/9929

  • Description of how to validate or test this PR
  1. Boot and update a current Raspberry Pi Picroft.
  2. Attach a HDMI monitor and speakers to the 3.5mm jack.
  3. Use raspi-config to configure headphones (=3.5mm jack) for sound output.
  4. Use Mycroft to play any wav or mp3 file: Prior to this commit, sound will be either heard through the HDMI monitor, if it is capable, of not at all. After this commit, sound will be heard through the speakers attached to the 3.5mm jack as selected via raspi-config.
  • Whether you have signed a CLA (Contributor Licensing Agreement)

Yes


Btw, the commented audio selection commands in this script are hence outdated as well: https://github.com/MycroftAI/enclosure-picroft/blob/buster/home/pi/audio_setup.sh
The problem is that it depends on the attached HDMI devices whether card 0 will be HDMI or 3.5mm jack, or the latter instead is card 1. Plugging of the monitor can hence as well break sound configurations. I'm hence no big fan of this new interface, but that's how it is. raspi-config now simply shoes the available sound cards with names to let the user select: https://github.com/RPi-Distro/raspi-config/blob/99a8ba5c74104a4c8f90c40fb4ac13df64d53fe0/raspi-config#L1925-L1952
The check above the highlighted code with bcm2835 ALSA sound device name btw only applies in case of outdated RPi kernel versions.

Since a recent Raspberry Pi kernel upgrade, ALSA sound card 0 device 0 is pointing to HDMI sound, if a monitor is attached, while 3.5mm jack then is card 1 device 0. Previously both were at card 0 device 0, switchable via amixer control.

Forcing now card 0 device 0 hence forces HDMI audio (even if the monitor does not really support it) and hence breaks 3.5mm jack sound. To allow switching the sound device with usual methods (ALSA configuration or raspi-config on RPi), Mycroft must not force the exact sound device. If no custom ALSA configuration exists, card 0 device 0 is the default anyway.

Related issues:
https://community.mycroft.ai/t/picroft-no-sound-with-3-5mm-jack-output/9726
https://community.mycroft.ai/t/sound-always-go-through-hdmi/9929

Signed-off-by: MichaIng <[email protected]>
@krisgesling
Copy link
Contributor

Hey Michael, I think we also need to update the setup scripts. Unfortunately there are some places expecting this particular string to do a search and replace for other hardware, eg:

sudo sed -i \
-e "s/aplay -Dhw:0,0 %1/aplay -Dplughw:ArrayUAC10,0 %1/" \
-e "s/mpg123 -a hw:0,0 %1/mpg123 -a plughw:ArrayUAC10,0 %1/" \
/etc/mycroft/mycroft.conf

maybe we can switch to jq so we aren't dependent on a very specific existing string, we just set values whether they exist or not, something like:

jq -c '. + { "play_wav_cmdline": "aplay -Dplughw:ArrayUAC10,0 %1" }' mycroft.conf > tmp.$$.conf && mv tmp.$$.conf mycroft.conf

@MichaIng
Copy link
Author

Wouldn't it make sense to configure the ALSA and/or PulseAudio directly instead? I don't know much about PulseAudio, but /etc/asound.conf/~/.asioundrc I mean, so that the system uses the desired sound device as default instead of having to configure every playback command separately?

Otherwise jq sounds like a robust solution, taking into account the strict JSON syntax I regularly fail at 😄, and to not depend on specific present settings that end users might manipulate.

I see there are other places where the RPi legacy audio interface is assumed:

case $key in
1)
echo "$key - Analog audio"
# audio out the analog speaker/headphone jack
sudo amixer cset numid=3 "1" > /dev/null 2>&1
echo 'sudo amixer cset numid=3 "1" > /dev/null 2>&1' >> ~/audio_setup.sh
audio="analog_audio"
break
;;
2)
echo "$key - HDMI audio"
# audio out the HDMI port (e.g. TV speakers)
sudo amixer cset numid=3 "2" > /dev/null 2>&1
echo 'sudo amixer cset numid=3 "2" > /dev/null 2>&1' >> ~/audio_setup.sh
audio="hdmi_audio"
break
;;
3)

It's a pain (IMO) but a 3.5mm choice cannot be reliably applied anymore without touching the device tree. On could loop through aplay -l or /proc/asound/card[0-9]/ identifiers to identify which one is "headphones" (=3.5mm jack) and which one is HDMI (if even present), but plugging or unplugging a HDMI device makes the 3.5mm sound card index change.

See here how we solved it via device tree overlay: https://github.com/MichaIng/DietPi/pull/3938/files#diff-e1f2e63b74209db8768bc28025d8727d20f2a2fa96ef44a0db7991724abeb507R1948-R1961
Not beautiful to go into such depths, but I couldn't find another way to have 3.5mm sound on a fixed card index that a reliable ALSA config can be based on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants