Mycroft CLI shows no Mic, test_microphone working

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

I am also starting from the 2018-01-19 v0.9.1 drop, and having similar difficulties to those shared above. I hope that some additional basic diagnostic scripts can be added to ensure success given all the variations possible here. In fact, on first activation it would be useful to engage a skill that simply had Mycroft ask the user to talk, and if nothing is heard, to point them at a useful URL to begin troubleshooting.

I’ve read through https://mycroft.ai/documentation/picroft/#audio-issues but there are discrepancies and gaps.

  • how can I tell which system is active at the current time, PulseAudio or ALSA? how to switch?
  • test_microphone works sometimes, does not work other times, what can I do to reset audio input?
  • is there any VU meter tool which shows input and allows me to adjust gain? even test_microphone has low volume
  • there is no ~/.mycroft/mycroft.conf file which one guide suggested adding alsa settings

My audio output has a constant hiss whenever the voice is not being used. This is an infamous Raspberry Pi gremlin.

1 Like
11

Try to get your mic name by “pactl list sources short”
For Example “alsa_input.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00-Device.analog-mono”

and set it with "pactl set-default-source “name” "

Do the same thing with “sink” for the output

12

Thanks for the suggestion to set the default source by its full name instead of by index. It did not change the situation. I followed that with a (sudo service mycroft-speech-client stop; sleep 5; sudo service mycroft-speech-client start) just to be sure.

I’ve tried two installs from scratch (starting with the 2018-01-19 v0.9.1 image) in case I messed something up with the first one.

I’ve tried three different USB microphones. The webcam-mic combo had the best sound in (test_microphone) and (arecord -d 10 test.wav; aplay test.wav), but all three produced recognizable audio.

As I mentioned before, there is always a low-level but definite speaker fuzz going on. It stops when the mycroft-speech-client is not running. This seems like mycroft is just suppressing all mic input while it is driving the speaker output (a reasonable way to avoid feedback loops) but it is driving speaker output all the time.

13

I’ve also had this problem and could fix it with this advice: Audio output "hiss" when should be silent · Issue #380 · raspberrypi/firmware · GitHub
Hope this helps with your issue.

14

Yeah, the hiss wasn’t bothering me so much as acting as a possible troubleshooting symptom, as driving speaker output maybe precludes receiving mic input.

I will confirm that adding the following will correct the hiss. (I think it should be added to the base picroft image.) The default /boot partition is mounted read-only, so editing the SD card while mounted on the PC, or having the raspberry remount the /boot as read+write is necessary to edit this file.

# Fixes to ensure silence without hiss on audio output.
disable_audio_dither=1
## audio_pwm_mode=2

The lack of response from the microphone remains.

15

Aha, I got some success.

There are some issues with the way the Picroft image is set up with two distinct users. The mycroft internals are all installed under a Linux user called mycroft, and the Raspberry Pi specific stuff (the so called “picroft enclosure”) is installed under the Raspbian user called pi. This distinction makes for some complex interactions with shared resources like skills and hardware access. The picroft enclosure user pi has commands like mycroft-cli-client but the rest of the system is really running as a daemon/service running as the mycroft speech client user mycroft.

I found that the mycroft user directory on Raspbian Jessie has almost no configuration but it does have a .config/pulse folder with some information about the default source and sink used for PulseAudio. However, it seems to be written or overwritten regularly, so this is more like a cache or cookie than a user-configurable item. Not sure what populates this folder with any files.

Instead, I went to the PulseAudio system-wide configuration file, /etc/pulse/default.pa and hardcoded my particular USB audio source and the headphone audio sink into the system-wide defaults. The names for the desired devices I used come from the pactl command, and then I un-commented two lines at the bottom of the default.pa file and inserted the names.

My names may differ from your system, but once set, you shouldn’t need to touch them again until you change audio hardware.

pi@picroft:~ $ pactl list short sources
0	alsa_input.usb-046d_080a_918E0EA3-02-U0x46d0x80a.analog-mono	module-alsa-card.c	s16le 1ch 48000Hz	SUSPENDED
1	alsa_output.0.analog-stereo.monitor	module-alsa-card.c	s16le 2ch 44100Hz	SUSPENDED
pi@picroft:~ $ pactl list short sinks
0	alsa_output.0.analog-stereo	module-alsa-card.c	s16le 2ch 44100Hz	SUSPENDED
pi@picroft:~ $ grep set-default /etc/pulse/default.pa 
set-default-sink alsa_output.0.analog-stereo
set-default-source alsa_card.usb-046d_080a_918E0EA3-02-U0x46d0x80a

After I rebooted, the wake word was immediately recognized with a tone confirmation. Anything else was rejected as “I didn’t catch that, please rephrase” by Mycroft until the system eventually loaded the training data. Now it responds as expected.

I hope this helps others get Picroft working correctly. I’ve delved quite a bit into the internals and decided to ignore all the other Linux and Python webpages which recommend “just delete PulseAudio, it is broken.” It may be a bad design, it may have bugs, but I did find a surgical workaround in this case.

2 Likes
16

Hold tight, we’re tracking a recent problem with Picroft and microphone, that has been present since last Thursday. More updates as they come to hand.

17

Can confirm this is working! It fixed my issue at last. Thanks a lot!

18

hey@ hariedo
can you please explain what you meant by " hardcoded my particular USB audio source and the headphone audio sink into the system-wide defaults " as I stuck at this step.
thank-you in advance!

19

@Nithish_Reddy, execute the two commands I show above that start with pactl. These list your audio sources (microphones, etc.) and your audio sinks (speakers, headphones, etc.). For me, I had a USB device which included a microphone, so the device name alsa_input.usb-046d_080a_918E0EA3-02-U0x46d0x80a.analog-mono was listed, but your device probably will have a different name. Once I chose the source and sink from that output, I edited my /etc/pulse/default.pa file (using sudo since it’s not owned by the pi user). I added two lines to that file, which I show above, each beginning with the words set-default-. Then I restarted the Raspberry Pi to ensure everything reloads.

This kind of workaround is called “hardwiring” because it makes the system less flexible. If you choose a new USB device, you have to go through this fix process again. If the Mycroft team fixes it in the future to be smart, then this hardwiring fix might get in the way of it.

20

@hariedo , Thank-you very much, for your help. Current update fixed my problem.

21

Where are we with this microphone problem? Are we waiting for a fix for a known problem, as the default.pa fix above is not working for me.

Mycroft is working fine. If I type commands into the cli they get actioned as expected and speech is working fine, but nothing showing on the mic level. Test-microphone works perfectly.

Using a raspberry pi with PS3 eye, which worked fine with alexapi, but Id rather use mycroft.

Am I missing something? Here is the end of my default.pa (I have commented out the “suspend” bit too).

### Make some devices default
set-default-sink alsa_output.0.analog-stereo.monitor
set-default-source alsa_input.usb-OmniVision_Technologies__Inc._USB_Camera-B4.09.24.1-01-CameraB409241.analog-4-channel-input

Many thanks for any help. Happy to wait if that is the only option.

22

Thanks, we’re currently testing a new Picroft image right now, @boik99.
You can test it for yourself at https://mycroft.ai/to/picroft-unstable

Kind regards, Kathy

23

Excellent, thanks Kathy. I shall give it a go and report back. Might not be til next week as we have our grandsons 1st birthday this weekend.

24

A very happy birthday to your grandson, @boik99! :cake: :candle:

25

Thanks Kathy. Maybe I should get Mycroft to sing Happy Birthday to him!

1 Like
26

Kathy, some good news! Just had a quick 10 minute play with the unstable version and wake word detection works out of the box. However, I am getting the following error:

15:52:46.850 - mycroft.client.speech.listener:transcribe:175 - WARNING - Access Denied at mycroft.ai

I hasn’t offered me a paring code, despite a couple of reboots. Have I missed something?

Thanks for your help so far.

27

Bit more from the logs:16:26:34.438 - mycroft.client.speech.listener:transcribe:175 - WARNING - Access Denied at mycroft.ai
16:26:34.443 - mycroft.client.speech.main:handle_utterance:61 - INFO - Utterance: [‘pair my device’]
16:26:34.466 - requests.packages.urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): api.mycroft.ai

16:26:35.225 - requests.packages.urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): api.mycroft.ai
16:26:35.834 - requests.packages.urllib3.connectionpool - DEBUG - https://api.mycroft.ai:443 "GET /v1/auth/token HTTP/1.1" 401 38
~~~~ycroft.metrics:report_metric:42 - ERROR - Metric couldn't be uploaded, due to a network error (The supplied authentication is invalid)

As an aside, the mic-level does not work on my first cli connection, but works perfectly if I start another session. Not a problem for me, juct thought it might mean something to you.
28

Any suggestions with the non-pairing issue Kathy? Seem to have taken one step forward and two steps back. I’ve check that the paring skill is there, and ran “msm default” just in case. Sort of out of ideas now.

29

Hey there @boik99 - did you remove any previous Devices that were created in home.mycroft.ai? That’s the only thing I can think of. Or, the microphone is not working, so the Pairing code is not being spoken - ie the pairing code exists but we can’t hear it.