Picroft configuration issue - no audio (mic or speakers) following setup, although both work fine in testing

Archive - Mycroft Project This category is being retired - Support
1

This has been maddening - I’m guessing I’m doing something stupid but whatever it is, it’s eluding me.

I start with what I suspect is a canonical deployment scenario: rpi 3, speakers on 3.5mm input rather than hdmi and snoball mic. During initial configuration, I have combo keyboard and trackpad connected on usb and a monitor on hdmi. Run through setup without issue, configure some skills and all is well. Specifically I can talk to the device, be heard, and hear the outcome of mycroft handling my directives. Then to prepare for moving the device to its intended location, I sudo shutdown, then disconnect the USB keyboard/trackpad and hdmi, move it to its new location and power it up. And it neither hears me nor will speak aloud. ssh to the device and I can do speaker and mic tests, which work successfully. In the microft cli I can type in directives and see the expected responses, but no audio is played on the speakers. The visual indicator for the mic in the cli shows either an invariant value or nothing at all.

I reproduced that scenario a few times on the stable 7-20 image and yesterday on the 9-26 one. Back when I was working with the 7-20 image, I thought that perhaps the removal of the USB keyboard/trackpad might be confusing mycroft about the addressing of the mic and so worked out a way to configure picroft without ever having either hdmi or keyboard/trackpad connected: install image and connect to laptop via direct ethernet connection; the pi will auto assign itself a link local address (169.254.*); work out what that address is, then ssh to it and run setup. When I did that, I would get through setup without issue - in particular the mic and speaker tests were successful - but once setup was complete I would end up in the same state as above: mycroft would neither receive audio input nor emit any audio output but would work in the cli in responding to typed directives.

I have a device running the 9-26 image which I will keep in this state to facilitate any desired log capture or debugging analysis, but given that this is very much an expected deployment scenario (the first one I described, not the ethernet/link local address one), I wonder if there’s a test description of it that I could review to see if there’s anything I’m doing differently?

2

Hi bucketman,

With the device in its non-working state can you SSH in and run:
mycroft-mic-test

Does this succeed like it did during install?

I’d also check alsamixer and make sure that the playback and capture volumes are at appropriate levels. The 3.5mm jack on the Pi is pretty low powered so output will likely need to be pretty high, whilst capture should generally be kept down around 30-50%.

In case you haven’t seen it, we have a page of things to try for audio troubles. I’m mostly surprised by the audio output not working. Mic issues are common, output from the audio jack much less so…

3

I think the audio troublshooting page has changed a bit since I saw it last - thanks for the reminder to check it out. I ran through what they suggest there and steps like the arecord test work as expected: recording proceeds without error and results in a file which I can aplay and hear on the speakers. I went ahead and set the default device for source via pactl. For sink, there was only one listed. Mixer settings were a weensy bit low so I bumped them up.

Regarding errors in the logs, the page does not specify a log location but I did a grep -r /var/log/mycroft for the two items mentioned on the page and did not find any occurrences.

Speaking specifically to your suggestion, I did the mycroft-mic-test and that worked fine also (recorded my clapping which I could then hear when it played the recording back).

In the cli, typing things like “say chicken” results in the response, “chicken”, being emitted as text in the cli but no audio, and the mic meter shows no measurement at all.

4

@KathyReid Do you have any suggestions on this topic? You’ve been super helpful in the past and I"m getting desperate - I want my mycroft back :slight_smile:

5

Hmmm, the problem is definitely isolated to Mycroft then.

Can you try setting the playback commands?

mycroft-config set play_wav_cmdline "aplay %1"
mycroft-config set play_mp3_cmdline "mpg123 %1"

Have you previously edited any of your mycroft.conf files? You can check the contents using:

mycroft-config show user
mycroft-config show system
1 Like
6

Thanks much for the followup @gez-mycroft.

Have I edited the mycroft.conf file - I have:

(.venv) pi@picroft:~ $ cat /etc/mycroft/mycroft.conf.bak 
{
   "play_wav_cmdline": "aplay -Dhw:0,0 %1",
   "play_mp3_cmdline": "mpg123 -a hw:0,0 %1",
   "enclosure": {
      "platform": "picroft"
   },
   "tts": {
      "mimic": {
         "path": "/home/pi/mycroft-core/mimic/bin/mimic"
      }
   },
   "ipc_path": "/ramdisk/mycroft/ipc/",
   "openHABSkill": {
        "host": "192.168.1.50",
        "port": "8080"
   },
   "listener": {
      "device_name": "Blue Snowball: USB Audio (hw:1,0)"
   }
}

Note that this is not the conf file I’m running currently - I went back to the below to see if my edits to the conf file were the cause of the problems:

(.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",
   "enclosure": {
      "platform": "picroft"
   },
   "tts": {
      "mimic": {
         "path": "/home/pi/mycroft-core/mimic/bin/mimic"
      }
   },
   "ipc_path": "/ramdisk/mycroft/ipc/"
}

The two commands you asked that I run resulted in the same warning:

(.venv) pi@picroft:~ $ mycroft-config set play_wav_cmdline "aplay %1"
/usr/lib/python3.5/runpy.py:125: RuntimeWarning: 'mycroft.messagebus.send' found in sys.modules after import of package 'mycroft.messagebus', but prior to execution of 'mycroft.messagebus.send'; this may result in unpredictable behaviour
  warn(RuntimeWarning(msg))
(.venv) pi@picroft:~ $ play_mp3_cmdline "mpg123 %1"
-bash: play_mp3_cmdline: command not found
(.venv) pi@picroft:~ $ mycroft-config set play_mp3_cmdline "mpg123 %1"
/usr/lib/python3.5/runpy.py:125: RuntimeWarning: 'mycroft.messagebus.send' found in sys.modules after import of package 'mycroft.messagebus', but prior to execution of 'mycroft.messagebus.send'; this may result in unpredictable behaviour
  warn(RuntimeWarning(msg))

Note that following this, there were no changes to the mycroft.conf file, so I made those changes manually and rebooted the device. But no joy - same situation, no visual indicator of mic input in the cli, no audible output from cli directives like “say chicken”.

7

The mycroft-config commands are just our new tool to help people edit these files, as we get a lot of errors caused by invalid JSON. If you’re ok editing the .conf files directly then go for it. Just be careful with the comma’s etc.

It looks like there’s a tiny typo in the play_wav_cmdline with no space after the -D flag. I’m also pretty sure that the -D for device name refers to the more human readable name rather than the card and device numbers.

I also think the listener.device_name attempts a starts_with match rather than requiring the whole string, so truncating that may help.

Putting these together, I’d first try editing these lines:

{
   "play_wav_cmdline": "aplay %1",
   "play_mp3_cmdline": "mpg123 %1",
   "listener": {
      "device_name": "Blue Snowball"
   }
}

If that doesn’t work then run
aplay -L to get a list of your device names
and follow the example here to use that with -D

8

Tried both of those and no dice. Here’s how my mycroft.conf file reads currently:

{
   "play_wav_cmdline": "aplay -D hw:0,0 %1",
   "play_mp3_cmdline": "mpg123 -a hw:0,0 %1",
   "enclosure": {
      "platform": "picroft"
   },
   "tts": {
      "mimic": {
         "path": "/home/pi/mycroft-core/mimic/bin/mimic"
      }
   },
   "ipc_path": "/ramdisk/mycroft/ipc/",
   "openHABSkill": {
        "host": "192.168.1.50",
        "port": "8080"
   },
   "listener": {
      "device_name": "sysdefault:CARD=Snowball"
   }
}

In this configuration, I’m in the same state as i originally reported:

  • mycroft-mic-test succeeds in both recording me and playing the recording back
  • in the mycroft-cli there is no visual mic state displayed
  • the device does not respond to the wakeword
  • mycroft-cli directives like “say chicken” emit the text “chicken” in the cli but nothing is played on the speakers

Is this configuration (analog audio out, rpi3, snowball mic) one that is tested prior to release of picroft versions? I’m asking this in order to establish whether or not this is a known working configuration.

9

I admit I’m a little surprised this doesn’t have a straight forward answer as I thought the rpi 3 + analog audio out + snowball mic was very much the canonical picroft deployment. Also note that I’ve reproduced this issue repeatedly and on different releases of picroft.

I did try replacing the power supply as I’ve seen rpis get up to no end of mischief with inadequate power.

One thing I’m not sure I’ve tried is replacing the rpi board itself - I’ve got lots so will try that before I move on. If anyone would like logs or specific debugging steps taken before I do so, please do speak up.

10

@bucketman If you would like to give it another shot, let’s see if the two of us can figure it our and get you going.

First of all. Do you have pulseaudio installed?

1 Like
11

In the end I did figure this out - well sort of. It appears to be a race condition in initialization in the picroft images - note I was able to reproduce this issue again on the 2020-01-10 image as well. To work around the problem, I ssh to the rpi and do a mycroft-start restart all and both audio in and audio out are working again. But every cold start triggers the problem anew.

2 Likes
12

Thanks for reporting back your findings.

I remember someone reporting similar behaviour on a Linux install but I’ll have to do some digging to see what we found in that instances, and what hardware was in use.

13

For reference, some additional hardware information in case it helps to search for the cause:
I had the exact same issue and behaviour and resolved it by restarting all without a cold restart as well.

My hardware is a Pi3, using the analog output and a RODE NT-USB microphone, Mycroft-core 20.2.3. I installed the image using Etcher on a Lenovo IdeaPad Laptop running Fedora (29, I think…).