Audio quality goes down when rhasspy is running

Help
#1

I have stumbled upon something I found weird. When I setup rhasspy on a new satellite (rpi4) with a respeaker 2 mic for both input and output. Same setup i have on 2 other satellites, except they are rpi3B. I noticed the little beep when the speaker wakes up and the little beep when its done listening, both sounded crackly. So I started to troubleshoot and see if I set up something wrong.

I copied the beep_hi.wav out of my docker container and started testing some aplay commands to see if I can get it to sound right. No matter what I did, it sounded crackly. I was starting to think I had a hardware problem. That was until I for some reason stopped the docker container rhasspy was running in and then tested the beep again and it sounded clear, just like I was originally expecting.

I started the container again, tested the beep and it was crackly again. So I removed the docker container and installed the debain package. Started up rhasspy and tested the beep. It sounded crackly. I stopped rhasspy and the beep was clear again. I tried switching to a 64 bit version of raspian bullseye just to see if that would help. Problem was the same. So I went back to 32 bit and problem still existed. I am very confused why rhasspy in a docker container would effect to output quality of a wav file that is not in the docker container.

So for my actual question. Is rhasspy somehow effecting audio output for the whole system when rhasspy is running? whether its a docker container or not. And if it is, how do I get rhasspy to output the audio at a better quality?

#2

Often its the container that throws us as it is an isolated container and the host has the alsa settings driver but not the docker entries to share or copy them across.
Also another is hw:0 like addressing is used whilst plughw:0 is the addressing that has rate, format and all the auto converters as for many cards 16k S16_LE isn’t a natural format and that can often cause problems and direct hw:0 addressing is a bad idea.

#3

Hey Rolyan, thank you for the reply. It sounds like to me there are kind of 2 problems. The audio config is not being shared with the docker container and the addressing in the alsa config is not set up nicely. Below is what my asound.conf file looks like:

defaults.pcm.rate_converter "samplerate"

pcm.!default {
    type asym
    playback.pcm "playback"
    capture.pcm "capture"
}

pcm.playback {
    type plug
    slave.pcm "dmixed"
}

pcm.capture {
    type plug
    slave.pcm "array"
}

pcm.dmixed {
    type dmix
    slave.pcm "hw:seeed2micvoicec"
    ipc_key 555555
}

pcm.array {
    type dsnoop
    slave {
        pcm "hw:seeed2micvoicec"
        channels 2
    }
    ipc_key 666666
}

To be perfectly honest with you, im not sure what half of that stuff means, but this was configured by the install script for the respeaker mic. I was trying to get a rate set in here but anywhere I tried to add it, I got an error.

#4

You don’t have to set the rate as the playback & capture use plug than hw so auto convert for you.
Even though the hardware is shared is there a /etc/asound.conf in the container?

docker run -d -p 12101:12101 \
      --name rhasspy \
      --restart unless-stopped \
      -v "$HOME/.config/rhasspy/profiles:/profiles" \
      -v "/etc/localtime:/etc/localtime:ro" \
      --device /dev/snd:/dev/snd \
      rhasspy/rhasspy \
      --user-profiles /profiles \
      --profile en

at a guess its -v to share so a line -v “/etc/asound.conf:/etc/asound.conf” but that would mean the ipc_keys are the same as you might just have to create a asound.conf somewhere and share that with 555556 / 666667
To be honest not sure why respeaker do that as the dmix & dnsnoop allow multiple access but prob never is.

docker exec -it <mycontainer> bash to connect to the container as it doesn’t matter what you have as config on the host as you need to think of the container as another computer.
You might want to run the docker exec 'apt install alsa-utils alsa-plugins ’ and test inside the container

#5

This seems to be an issue with the bullseye OS. I have done a lot of testing to see where the problem was. I have swapped out different speakers, different pi hats, different raspberry pi’s both rpi4 and rpi3 and the latest test was using raspbian buster instead of bullseye and the issue is not present. I have been reading and have found that bullseye has a lot of compatibility issues with some pi hats and im wondering if that problem is present here

#6

Maybe but I have had the 2mic running recently on Bullseye no Rhasspy just on the host and no problems.
Well biggest problem with my old eyes was I thought I had pulled the power and it killed the I2s on my pi400 but still works on others and spent some time with a pi3 and new images seeing if I could get the pi400 I2s back to life but card worked fine.