Mycroft CLI shows no Mic, test_microphone working

So lately I have installed a fresh image of the picoft on my Raspberry Pi 3 and suddenly the device wouldn’t recognize my Microphone any more. Got it to work again for test_microphone though (by pactl set_default_source) but when opening mycroft-cli-client on the right bottom there is no microphone level.
It has worked before but now doesn’t do anymore, so should not be an issue of any drivers. Wakeup-word and engines are set to default yet before the crash I attempted to change them via which resulted in the crash.

Using picroft on the Raspberry Pi 3 with a working USB-Microphone and jack speakers. The logs show no errors (aside from some in mycroft-skills but that wouldn’t hinder wake-word recognition as far as I know.)

Thanks in advance for your support.


Hi Nielstron - we have some basic RPi audio troubleshooting doco here:

Does any of this help?

Best, Kathy

Hi nielstron,

From your screenshot it looks like an ssh session with putty, try it directly on the console in an Xsession. Also, sometimes the first time the cli starts it wont show the mic level, but quit and restart the cli and it usually shows it.

If it shows the mic level but then it freezes after a few moments, I have that problem, and using it in the gui console works for me.

HI Nielstron, in my case i’ve upgraded to the latest rpi kernel:

sudo rpi-update
sudo apt-get update && sudo apt-get dist-upgrade

check mic volume with the command


then press F5 and F6 (select mic on the list and adjust the volume as needed)



So I did a complete new installation based off the new Image from january 19th. With arecord -l the console shows

**** List of CAPTURE Hardware Devices ****
card 1: Microphone [Yeti Stereo Microphone], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

The device is also listed with arecord -L and pacmd list-sources.test_microphone again working fine.

Yet again mycroft is not responding to the (default) wake word and no volume is shown in mycroft-cli-client.Fiddeling around with alsamixer doesn’t seem to help anyhow as the volume is high enough.

I also don’t have another Linux device or screen to directly access the pi, have to do it via putty.

Also I am a bit confused about the default value of the wake up phonemes. It is HH EY . M AY K R AO F T. Is this a correct value? After skimming through some other posts I thought there should be a “.” at the end.

You could try the following :slight_smile:

make a ~/.asoundrc file following instructions here to ensure that usb mic is working (from your troubleshooting it sounds like it is though)


Check your mycroft.conf file (check in all locations for it, I think there 3 are local)

“play_wav_cmdline”: “aplay -Dhw:0,0 %1”, <----- I think this is for audio though, but nothing worked until I had this line


Whilst in CLI Debug, stop and start the voice (I think) service from a second putty session

./ voice <-- wait a few seconds
./ voice

Does the mic level appear ? Does it appear then freeze ? (your screen shot seems to show it, but no ‘live’ marker bar).

The Phoneme looks ok to me, but you can login and set defaults on the website - did you change the voice or the TTS or STT at all ? Default them just in case.

Good luck

1 Like

Thanks for your support. I have tried setting up a asountrc file, put it both in the pi as well as in the mycroft home directory but that didn’t work. The line you mentioned was already in /etc/mycroft/mycroft.conf.

Also I am running PiCroft where there are no scripts for starting or stopping mycroft services (at least I didn’t find them). After a reboot yellow markers for the mic level appear in the cli but stay at zero/the threshold mark. After a second start of the cli nothing shows up there anymore.

I once changed the TTS/STT systems but mycroft didn’t react afterwards so I set them back to default. I think to remember that it didn’t work afterwards anymore, could this have caused any crashes?

I’ve just done a full rebuild myself (I’m currently working on a fully mobile assistant with object / face recognition opencv3, autonomous movement, environment learning & assistant capabilities) - so have been rebuilding on a regular basis - across 3 Pis (ouch) - oddly each build is slightly quirky…

However, my best results for my bespoke setup have been using Ubuntu Mate on the Pi3 - I tried the Pi image a while back and found it ‘fiddly’ - maybe my tendency to tinker - try this image - use a different SD card (so you have a jessie & a ubuntu build), I suggest a 16gb Sandisk class 10 (screams along).

Anyway - Etcher the image, boot it, apt-get update / upgrade / dist-upgrade, do your personal config as usual (setup ssh, config sound, test base build, install mycroft as pi user)

cd ~/
git clone
cd mycroft-core

I run as pi user (historically in X console as root, but now works as pi on command line for me)

cd ~/
sudo ./start-mycroft all
count to 10…
sudo ./start-mycroft cli

Fingers crossed… now, you may not see the mic level moving until after ‘Training Completed’ - this can take a minute or two.

Ok, if still no joy, try /usr/bin/pulseaudio --start (try before you run mycroft)

Check previous posts (above) to confirm config. Check raspi-config set to 3.5mm, all the obvious stuff (I usually forget something).

Still no joy, get back to me - happy to help.

1 Like

OK, I’m really stuck.

I have plenty of Raspberry Pi experience, and have even got this setup to work with Google Voice Assistant SDK, so I know for sure that my microphone (a USB webcam, in this case) is working just fine.

But I cannot get Mycroft to use my microphone.

I have tried all the steps in the “troubleshooting” section (although the instructions about the mycroft.conf editing is a little ambiguous, i.e. I don’t really know where this property should be nested in the JSON?), added a .asoundrc file in both the pi and mycroft home folders. I’ve run test_microphone script and that works perfectly (records and plays back sound as expected).

But when the Pi boots up, I can see the webcam mic being switched on (the light goes on) and then a few seconds after the mycroft CLI itself has started, the light is off.

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 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

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

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.

I’ve also had this problem and could fix it with this advice:
Hope this helps with your issue.

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.
## audio_pwm_mode=2

The lack of response from the microphone remains.

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/ 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 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/ 
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.


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.

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

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!

@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/ 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.

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