Mycroft on Ubuntu Mate not listening


#2

No clue? :anguished:


#3

Hi @SamKr

Sorry for the lack of responses, we’ve had a little change over in staff with Kathy leaving and I’ve been trying to catch up on the forum.

Have you had a look in pavucontrol this is a GUI mixer for PulseAudio so can be clearer than the alsamixer.


#4

Jep, looks fine:

Welcome by the way :slight_smile:


#5

Thanks for the welcome and the clear screenshots + logs :slight_smile:

It definitely looks like your pulseaudio defaults are set correctly based on the screenshots and given your recording and playback is working.

Can you launch pavucontrol and have a look at the ‘Recording’ tab
After you launch ./start-mycroft.sh debug does it show the ALSA python plug-in as a stream?

If you launch Mycroft without the Snowball plugged in, does it register your internal mic?

Finally have you restarted your whole system recently? Just in case the magic restart fairy fixes everything for us.


#6

Nope, nothing recording! You may be on to something here. Any idea where/how to debug?

Without snowball it registers the internal mic, but no difference, probably because of the nothing-recording problem.

Rebooted multiple times, usually does the trick but not this time heh


#7

I wonder if it is related to this other issue we just resolved with a different USB device? Can you check your mycroft.conf as it details here:


#8

No luck, but that seems to be focussed on playback?

When running ./start-mycroft.sh audiotest everything works fine, and the plugin shows up as seen in the screenshot below. But as soon as it stops, it disappears, and running Mycroft doesn’t get it back. Does the test somehow use a different plugin? Or perhaps because of the virtual env mycroft is running in?


#9

Hi Sam,

That is interesting that the audiotest works but Mycroft doesn’t.

I saw in your original logs that /etc/mycroft/mycroft.conf was not defined and hence skipped. Is that still the case? Can you post the output of cat /etc/mycroft/mycroft.conf

And have you made any modifications to ~/.mycroft/mycroft.conf? As this will override anything in /etc/mycroft/mycroft.conf


#10

There was no /etc/mycroft/mycroft.conf but I created it myself (see this post). It now only contains the TTS tag.

Also, I did make changes to ~/.mycroft/mycroft.conf, but as they got overwritten I created the /etc one. It now only contains one tag, something like ‘max allowed version’ (not near the machine atm).

Is there supposed to be a conf in /etc by default?


#11

Hi @SamKr I have the same issue recently, and I solved making a Reconfiguration of the Locales with the next command

sudo dpkg-reconfigure locales

I was following the next link

picroft-not-picking-up-voice

I really dont know how this resolve it :sweat_smile: but it works for me. I use the option “all” locales and it take a bit long to finish the reconfiguration but mycroft started listening to me :grinning:

About the configuration file, I found it in …/mycroft/configurations/mycroft.conf

PS: sorry if i struggle with the english :no_mouth:


#12

Thanks @michaelmfzv for taking the time to respond :slight_smile: I tried your advice; it’s true that I didn’t have a language set, so I ran the commands and tried both en-US and en-GB but nothing changed :frowning:

However, I do have this message in voice.log:

21:05:30.837 - mycroft.client.speech.listener:_load_config:235 - DEBUG - Using microphone (None = default): None

And the following error message keeps popping up in audio.log, but I don’t think it’s related:

21:05:39.950 - mycroft.audio.audioservice:load_services:110 - ERROR - Failed to import module mplayer
ModuleNotFoundError(“No module named ‘py_mplayer’”,)

Is there no dev around that can at least point to a direction as to why recording works during the test, and not when running Mycroft? I’ve already logged considerable hours into this and I haven’t even written a single line of code :confused:


#13

Hi Sam,

Sorry that it’s still not working, audio is a challenge with so many variables across machines and different configurations.

It would be good to try and specify the exact device that Mycroft should use through the config. We usually leave it set as essentially ‘system default’ but in this case that clearly isn’t working.

1. To get your device name we’ll use this script

$ cd ~/mycroft-core
$ source venv-activate.sh
$ wget goo.gl/TsUAaK -O list_inputs.py
$ python list_inputs.py

At the bottom of the output it should have something like:

==========================================
Found devices:
HD-Audio Generic: ALC892 Analog (hw:1,0): Samplerate 44100.0 Channels 2
HD-Audio Generic: ALC892 Alt Analog (hw:1,2): Samplerate 44100.0 Channels 2
pulse: Samplerate 44100.0 Channels 32
default: Samplerate 44100.0 Channels 32

Copy this somewhere so you can reference it.

2. Specifying the device in mycroft.conf

Exit venv if not already ~ $ mycroft-venv-deactivate
Edit configuration file ~ $ nano ~/.mycroft/mycroft.conf

Add the following lines:

"listener": {
    "device_name": "DEVICE_NAME"
  }

Where “DEVICE_NAME” can be pulse or in the example output above “HD-Audio Generic: ALC892 Analog (hw:1,0)”

3. Restart Mycroft
To make sure it’s fully restarted run:

$ cd ~/mycroft-core
$ ./stop-mycroft.sh
$ ./start-mycroft.sh debug

I’ve also flagged this post with one of our core dev’s to see if they have any other ideas about what might be happening particularly given discrepancy between the audiotest and real usage.


#14

Since the release yesterday the audiotest has an option to list the available devices:

./start-mycroft.sh audiotest -l

which should be simpler than the script I published as a gist.

At this stage we might want to check the voice.log for any errors. The voice.log is found in the folder /var/log/mycroft/ Can you upload this file to pastebin.com or similar service?

Do you get the “Ding” indicating that the device has heard “Hey Mycroft”?


#16

I accidentally withdrew the last post :roll_eyes:


@gez-mycroft Awesome, that seems to have done it :slight_smile: It defaulted to nothing, no mic or anything. Think that’s something that Mycroft can maybe implement in the installation or configuration script, to manually select a microphone as a default instead of using the system wide default.

Weird thing is though, that while I can see voice.log scanning for the mic I defined in the conf, it still shows this line at the end of it:

09:31:31.713 - mycroft.client.speech.listener:_load_config:235 - DEBUG - Using microphone (None = default): None

But nevertheless, now it works. The :meter show command doesn’t work though, but pavucontrol shows the Python plugin is recording.

@forslund: Thanks for your reply. I tried using the audiotest -l command, but it just froze at ‘initialising’… So I used the script anyway.

For future reference, you can find the voice.log here. It wasn’t showing errors before, half of the time it wasn’t logging anything.


#17

Great to hear that it magically started to work.

The device setting of stuff seems a bit strange and I’ll look into it.

09:31:31.644 - mycroft.util:find_input_device:174 - INFO - Searching for input device: Blue Snowball: USB Audio (hw:1,0)
09:31:31.645 - mycroft.util:find_input_device:175 - DEBUG - Devices:
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
09:31:31.700 - mycroft.util:find_input_device:180 - DEBUG -    HDA Intel MID: ALC270 Analog (hw:0,0)
09:31:31.701 - mycroft.util:find_input_device:180 - DEBUG -    Blue Snowball: USB Audio (hw:1,0)
09:31:31.703 - mycroft.util:find_input_device:180 - DEBUG -    sysdefault
09:31:31.704 - mycroft.util:find_input_device:180 - DEBUG -    front
09:31:31.706 - mycroft.util:find_input_device:180 - DEBUG -    surround40
09:31:31.707 - mycroft.util:find_input_device:180 - DEBUG -    surround51
09:31:31.709 - mycroft.util:find_input_device:180 - DEBUG -    surround71
09:31:31.710 - mycroft.util:find_input_device:180 - DEBUG -    pulse
09:31:31.711 - mycroft.util:find_input_device:180 - DEBUG -    dmix
09:31:31.712 - mycroft.util:find_input_device:180 - DEBUG -    default
09:31:31.713 - mycroft.client.speech.listener:_load_config:235 - DEBUG - Using microphone (None = default): None

Looks like it should find it but apparently not… I’ll check it out more.


#18

Alright :slight_smile: If you ever need more info, let me know.


#19

@forslund: I actually have more for you in case you get bored :wink:

I tried to switch from pocketsphinx to precise, but that didn’t go well as you can see here.

At 09:50:20.191 there’s actually an error, after that it seems busy recovering itself and now it’s constantly ‘still downloading executable’.

Mycroft indicates it’s using precise as the listener by the way, pavucontrol indicates Python is listening but there’s no voice response to ‘Hey Mycroft’. I’ll let it run for a while and after that revert to pocketsphinx.


#20

Thanks for reporting. Seems like some error handling is appropriate here. I tried to reproduce but couldn’t. Maybe a broken download but it’s a bit weird since the downloader should verify the checksum before extracting… I’m going to flag @Wolfgange to see if he has any suggestions.

In the meantime I suggest removing the ~/.mycroft/precise folder and restart the voice service to see if the a redownload solves the issue.


#21

Went back to pocketsphinx, shutdown Mycroft, deleted the ~/.mycroft/precise folder, restarted Mycroft and attempted to switch to precise - but same thing happened and it’s again in the ‘still downloading executable...’ loop.

New log here.

Fun fact; the :meter show function started working :slight_smile:


#22

Thanks for the update will try to figure this out…