search

MycroftAI / enclosure-picroft

Mycroft interface for Raspberry Pi environment
https://mycroft.ai/documentation/picroft
GNU Lesser General Public License v3.0
804 stars 191 forks source link

audio_setup.sh - philosophy #101

Closed fractal13 closed 5 years ago

fractal13 commented 5 years ago

I'm using the 2018-09-12 picroft image. The hardware is a RPi 3B+, with a Sony Playstation Eye, and a USB speaker.

The problem:

We created about 10 of these devices, and went through the configuration on each of the devices, using a USB keyboard and HDMI monitor (which has audio capabilities). We were able to get audio configured using auto_run.sh's functionality.

However, on reboot, the audio cards don't always get detected in the same order. Sometimes the audio would go to the HDMI speaker, sometimes to the USB speaker. Even worse, after detaching the HDMI monitor, a reboot may or may not have working audio.

My limited research:

It appears that the audio cards get detected in a non-deterministic way, so the configuration in /etc/mycroft/mycroft.conf that has devices configured directly in the aplay and mpg123 lines will be wrong.

My hack:

Full disclosure, I haven't been able to find documentation that makes the amixer cset commands clear to me. So, I couldn't get the current structure of the audio_setup.sh file to work reliably from boot to boot.

We found that using aplay -l (not aplay -L) helped to discover the current device major number, using expected strings (such as HDMI or USB 2.0). Eventually, we hacked audio_setup.sh to look for the correct device number and re-write the lines in /etc/mycroft/mycroft.conf. You can see the script here: https://raw.githubusercontent.com/fractal13/coding_zendo/master/audio/audio_setup.sh

My question:

Is anyone willing to talk about the audio configuration philosophy and strategy for Picroft? I wonder if it might be more reliable to offer the user a list of device names from the output of aplay -l, then remember that in a data file, and use it to rewrite the configuration with audio_setup.sh each boot?

I fully admit that I may be missing the point of why the current system should be more reliable, and thus have identified a non-problem.

If changes are desired, I would be happy to implement.

PS. The Spotify skill (at least the raspotify service) would be easier to configure as well, if we had a file somewhere that identified the correct audio device.

forslund commented 5 years ago

If it's more reliable I'd say we're all for it!

The device parameter seems to accept device names as well as card:device addresses. I wonder if those would remain more deterministic?

Another thing is that in the unstable image I think pulseaudio is used would that make a difference?

fractal13 commented 5 years ago

I'll look at the unstable image. pusleaudio may make a difference.

penrods commented 5 years ago

We updated the stable image also, now. Let me know if you are still seeing an issue, but I think we have this whipped now. There are a few newer config options you can also use to pick the active audio device using a name instead of an index if this proves necessary.