Rate doesn't match (requested 16000Hz, get 48000Hz)

[drigz]

From googlesamples/assistant-sdk-python#127

I am trying to get the AIY kit up without the Google supplied image. I have followed the steps in the HACKING.md file, however, when I start the service I see...

pi@raspberrypi:~/code/voice-recognizer-raspi $ source env/bin/activate(env) pi@raspberrypi:~/code/voice-recognizer-raspi $ python3 src/assistant_library_demo.py
ALSA lib pcm.c:8403:(snd_pcm_set_params) Rate doesn't match (requested 16000Hz, get 48000Hz)
[1215:1253:ERROR:audio_input_processor.cc(755)] Input error
Say "OK, Google" then speak, or press Ctrl+C to quit...
Segmentation fault

[drigz]

Possible workaround (from @shivasiddharth): delete ~/.asoundrc (or cp /etc/asound.conf ~/.asoundrc if this is happening repeatedly).

This may occur because another process has created an invalid ~/.asoundrc. If this is happening to you, please comment to let us know when the invalid file is created (eg when you reboot? when you change the volume?) and what it contains.

[drigz]

I have reproduced this partly:

1. Flash Raspbian 2017-09-07.
2. Follow instructions from HACKING.md, including rebooting.
3. Observe that ~/.asoundrc has been created, and that the volume widget doesn't work.
4. Delete ~/.asoundrc and reboot.
5. Observe that ~/.asoundrc is not there, and that the volume widget does work.

I was unable to trigger re-creation of ~/.asoundrc - it was only created on the first reboot. Here's what I tried:

• sudo reboot
• reboot from start menu
• pull power cable and restart
• sudo rm /var/lib/alsa/asound.state && sudo sync then pull power and restart

The system continued to work after all of these.

I'll try creating .asoundrc as a duplicate of /etc/asound.conf and seeing if that avoids the issue.

[drigz]

Contents of .asoundrc:

pcm.!default {
        type hw
        card 0
}

ctl.!default {
        type hw
        card 0
}

Which looks like it was created by the volume widget.

[shivasiddharth]

So the asoundrc is getting padded even with the contents of asound.conf ?

[drigz]

I don't know - I only tested the old instructions (only create /etc/asound.conf, then ~/.asoundrc gets auto-created by something else when you reboot the first time). I'm trying with your PR right now.

[drigz]

@shivasiddharth I tried with your PR but it didn't work: the panel crashes with a segmentation fault when you try to start it. I thought this is because it's trying to edit ~/.asoundrc but failing as it's owned by root, so I ran sudo chown pi:pi ~/.asoundrc and rebooted, but then I have the same problem: ~/.asoundrc is overwritten with the old contents.

Did you test your PR on a fresh install of Stretch? Are we doing something differently?

[drigz]

Weirdly, after having problem with the panel crash, I tried deleting /.asoundrc and rebooting, and it still didn't work (/.asoundrc was created as before...) but then deleting it again and rebooting again did work. I can now continue to delete and reboot and it works.

Theory:

• on the first boot, ALSA state is bad because the Voice HAT driver hasn't been loaded.
• on the first shutdown, bad ALSA state is saved
• on the second boot, bad ALSA state is loaded
• this causes the mixers not to work and the volume widget creates ~/.asoundrc
• we delete ~/.asoundrc, play some audio and it works
• the ALSA state is now good
• we reboot, and the new, good ALSA state is loaded and everything works

TBD: will the volume widget ever create another .asoundrc again? Is there any way to stop it doing that?

[shivasiddharth]

Yes i did test this on a fresh installation of raspbian stretch. My taskbar did crash, i thought it was due to VNC (Taskbar crashing in Raspbian has been a long standing issue so id did not suspect the asoundrc). After the taskbar crash, i normally open a terminal, run apt-update and reboot to get the taskbar back, along with volume icon and unaltered asoundrc.

[shivasiddharth]

I am curious to know whether this issue is not appearing with the ready to use AIY image. I shall dig into this taskbar issue over the weekend.

[drigz]

Who would have thought that a volume widget could cause so many different problems...

For now I'm going to merge the advice to delete ~/.asoundrc, since (a) it has worked for me several times (~4 installs, ~10 reboots) and (b) because I observed ~/.asoundrc getting overwritten, so it might be a false sense of security.

I'll also check with another engineer who has had experience with a similar issue - maybe they can help.

@shivasiddharth, thanks for reporting this and answering all my questions! Let me know whatever you find out this weekend and maybe we can improve the instructions or avoid the issue altogether.

[drigz]

Oh, and the current AIY image is still based on Jessie.

[shivasiddharth]

From the posts on Raspbian community, it looks like we are not alone on this. Here is a reply from an Engineer as to why this is happening https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=158618#p1171920
Currently, we are disabling the on-board audio and writing the audio configs in a single step, may be we should have a reboot in-between and split it into two steps. This corroborates your theory of unaltered asoundrc from second reboot. So i guess:

1. Install I2S (Disable on-board audio).
2. Reboot.
3. Copy the asound.conf and asoundrc.
4. Reboot again.

Will check on this and get back..

[drigz]

I think that may not be enough - you may need:

1. scripts/configure-driver.sh
2. reboot
3. scripts/install-alsa-config.sh
4. python3 checkpoints/check_audio.py
5. reboot

It seems ALSA doesn't update the state based on the new config/drivers until you play some audio, so you need to run check_audio or something similar.

[divx118]

@drigz @shivasiddharth couldn't alsactl init/restore actions help with that instead of a reboot. I don't own a voicehat so I can't test.

[drigz]

@divx118 I don't think so, unless you could stop the init scripts from saving/restoring the bad ALSA state on the first reboot.

[shivasiddharth]

@drigz , The updated instructions did the trick.. worked 10/10.. even speaker-test is sufficient to initialize alsa if not the check_audio.py. Also, the PR is no longer needed. If after merging the PR someone skips the audio check, taskbar will go missing, if the PR is not merged at least it will just be the audio icon..
The hacking.md of both the voicekit and master needs to be modified.