Default play_* system settings on picroft are hard coded to device 0,0

[fermulator]

Introduction

Have been using mycroft on a Linux system for a while, switching to the lower power picroft on raspberry pi. The installation was fairly smooth, however I've run into a bit of "awkward" defaults resulting in lost hours until I figured out all the audio configuration components.

Hoping to walk us through the primary issues here ... and make recommendations for improvement / fixing. (happy to tackle PRs if core team agrees w/ the proposals)

Setup

• I'm running a Raspberry Pi 3B+
• With version 20 oh 2, release 4 of the Mycroft software
• With the standard Wake Word (Hey Mycroft)
• Using audio: Bus 001 Device 004: ID 08a8:0016 Andrea Electronics (this WORKS btw! submitted PR to supported hardware here: add Andrea Electronics USB SUMA documentation#178) - this came with a USB mic+speaker adapter (which worked great on the linux system) - my GOAL is to use this on the raspberry pi

Reproduction Steps

1. Installed picroft! (https://mycroft-ai.gitbook.io/docs/using-mycroft-ai/get-mycroft/picroft), etc
2. At first since I was connected over HDMI, the default sound was coming out of the TV LoL
3. After removing HDMI from the picture, I then hooked up my USB device and executed the wizard.
4. Microphone worked immediately, but sink (output/speaker) wasn't working.
5. Then I moved the speaker to the built-in 3.5mm jack, and THAT worked (but gawd it is so quiet)
6. Debug time: https://mycroft-ai.gitbook.io/docs/using-mycroft-ai/troubleshooting/audio-troubleshooting
7. Walked through ALL of that, and came to the conclusion: the SYSTEM works (I can play a sound out of either the built-in 3.5mm or the USB adapter, changing pulse' defaults accordingly) using aplay ./mycroft-core/mycroft/res/snd/start_listening.wav -- BUT -- mycroft output sink refused to work! Well behold isn't it wierd that we only have a listener.device_name configuration? - it was null at first, tried both pulse and default ... nothing mattered.
8. FINALLY I stumbled over /etc/mycroft/mycroft.conf and some Internet research ... bah! The system config here overrides the defaults ... completely undermining the audio troubleshooting documentation. The playback commands are HARD CODED to device 0!! ;/

(.venv) pi@picroft:~ $ cat /etc/mycroft/mycroft.conf
{
   "play_wav_cmdline": "aplay -Dhw:0,0 %1",
   "play_mp3_cmdline": "mpg123 -a hw:0,0 %1",

^^ this was the culprit; after removing that hard coded, OR setting it to the right hard coded, and rebooting the pi, everything worked!

Be as specific as possible about the expected condition, and the deviation from expected condition.

When a user executes a first-time installation, and followed the audio troubleshooting to walk through the workflow and isolation steps of audio issues, they SHOULD be able to arrive at a conclusion of "unsupported hardware" vs. "supported hardware", and a working mycroft installation purely through that documentation (or at least within the scope of mycroft ... raspberry pi specific HW stuff is a bonus).

Here follows relevant configurations:

(.venv) pi@picroft:~ $ lsusb
Bus 001 Device 004: ID 08a8:0016 Andrea Electronics 
(snip)

(.venv) pi@picroft:~ $ pactl infofo
Server String: /run/user/1000/pulse/native
Library Protocol Version: 32
Server Protocol Version: 32
Is Local: yes
Client Index: 42
Tile Size: 65496
User Name: pi
Host Name: picroft
Server Name: pulseaudio
Server Version: 12.2
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.usb-Andrea_Electronics_Andrea_PureAudio_USB-SA_JUNE_2010-00.analog-stereo
Default Source: alsa_input.usb-Andrea_Electronics_Andrea_PureAudio_USB-SA_JUNE_2010-00.analog-stereo
Cookie: 7904:7177

(.venv) pi@picroft:~ $ aplay -ll
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: USBSA [Andrea PureAudio USB-SA], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

this works (and various combos)

(.venv) pi@picroft:~ $ aplay -Dhw:1,0 ./mycroft-core/mycroft/res/snd/start_listening.wav
Playing WAVE './mycroft-core/mycroft/res/snd/start_listening.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

(.venv) pi@picroft:~ $ aplay ./mycroft-core/mycroft/res/snd/start_listening.wav
Playing WAVE './mycroft-core/mycroft/res/snd/start_listening.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

(when the default pulse sink is of course set to the USB andrea device)

Proposals

1. in the documentation for how to test output, we should use aplay ./mycroft-core/mycroft/res/snd/start_listening.wav instead of the "listen/record mic, then play that" (because that causes a dependency on the mic working)

2. the DEFAULT in /etc/mycroft/mycroft.conf, should IMO be:

(.venv) pi@picroft:~ $ cat /etc/mycroft/mycroft.conf
{
   "play_wav_cmdline": "aplay %1",
   "play_mp3_cmdline": "mpg123 %1",

, we really shouldn't be hard coding the playback device at the mycroft system config level! (not by default anyway) - let it play out of the default, and help the user to understand how to have pulse default sink/source configured (as the docs already do!)

EDIT: see MycroftAI/enclosure-picroft#132

3. we should add to the the documentation how to OVERRIDE the system defaults (imagine a system where it had multiple purposes ... maybe the mycroft mic/speaker should be different from the defaults?) - in this case, we should mention:

• (A) set the listener.device_name in the user configuration mycroft-config set listener.device_name <DEVICE> (as per the docs)
• (B) edit the system configuration playback commands (add to docs) - OR - FUTURE - add a new configuration for playback device within mycroft system config? (we can mention the ability for those playback commands to specify the device, but IMO hard coding the IDs in the playback commadn flags feels hacky and prone to screw people over)

[forslund]

You are correct that the play_* commands no longer should be part of the picroft config. They were once needed to workaround a pulse/alsa issue in Debian Jessie, so they were added as a system level default value (overridable by the the user config).

In any case I think the bug in Debian has been fixed and the config could be removed. Maybe open a separate issue in enclosure-picroft?

[fermulator]

@forslund thanks for the tip, I searched issues there and found: MycroftAI/enclosure-picroft#132, so that covers us for (2) of the proposals above (updated main description too)

[forslund]

Regarding 1, do you think it would be beneficial to have the audiotest command to add a test step for just output. Playing the ding sound, it could also be extended to try creating a sentence using mimic and test that that is working.

[fermulator]

@forslund sounds good; want me to take a stab? thinking roughly it is simply
1.(A): add the aplay ding
2.(B): mycroft-speak hi

is that what you're thinking?

[forslund]

Yeah, with some output text like "playing audio on default device", "speaking a test sentence"

Not sure mycroft-speak can be used 100% reliably since that requires mycroft (or the audio process at least) to be running. My thought yesterday was to use the mimic executable directly either from system path or mycroft-core/mimic/...

another option is to spin up the TTS module from the audiotest

Something like

from unittest.mock import Mock
from mycroft.tts import TTSFactory
    
    tts = TTSFactory.create()
    tts.init(Mock())
    tts.execute('Hi')

(Totally untested code so I'm not 100 % it's correct)

Edit:
I personally think it's a good idea but I'm just a community member nowadays so someone on the team will need to make the call if it's something they want to include.

[fermulator]

@krisgesling ; does the proposal sound good? - if so I'll get a PR in

[krisgesling]

Hey there, thanks for nudging me on this. It does sound good!

On the three proposals specifically:

1. This would be a good update to the docs, and as you've been talking about it would be even better if this was added to the existing audiotest so we can point people to a single command that tests recording, output, and mycroft speech.
2. Sounds like this should be removed, we'll just want to test it well to make sure we don't break existing setups.
3. Any improvements to the documentation on this would be very much appreciated!

[forslund]

Closing Issue since we're archiving the repo