Can't get microphone capture working, even though capture device is recognized

I’ve been banging my head against the wall trying to solve this problem for days now.

I am setting up a base and satellite Rhasspy setup.

  • On my 8GB HomeAssistant RPi 4, I’m running supervised HA with the Rhasspy v2.5.11 (full, not junior) addon, configured perfectly with the Anker S330. I’ve got audio and wakeword detection working solidly there.
  • On my 1GB RPi 4 running Raspberry Pi OS Lite v5.15, I have Rhasspy v2.5.11 installed in a Docker container. In both the host and inside the Docker container, I can see the device listed as both playback and capture in aplay -L and arecord -L.

Output from arecord -L:

null
    Discard all samples (playback) or generate zero samples (capture)
output
input
default
hw:CARD=S330,DEV=0
    Anker PowerConf S330, USB Audio
    Direct hardware device without any conversions
plughw:CARD=S330,DEV=0
    Anker PowerConf S330, USB Audio
    Hardware device with all software conversions
sysdefault:CARD=S330
    Anker PowerConf S330, USB Audio
    Default Audio Device
front:CARD=S330,DEV=0
    Anker PowerConf S330, USB Audio
    Front output / input
dsnoop:CARD=S330,DEV=0
    Anker PowerConf S330, USB Audio
    Direct sample snooping device

All audio playback works great on both the host and from the Docker container (via Rhasspy’s audio output); however, for the life of me, I cannot get arecord to record a test wav file on the host. I’m constantly met with the arecord: main:830: audio open error: No such file or directory error, about which I’ve scoured the net for more info to no avail. All I can surmise is somehow, the capture device isn’t being properly started.

Furthermore, I can change audio levels for playback and capture for the S330 in alsamixer with no issues on both the host and from the Docker container, so it appears that the host audio devices are properly passing through to the Docker container. I’m not sure if it makes a difference since the capture device shows in arecord -L, but in /proc/asound/devices, I see entries for digital audio playback, but nothing for capture at all.

I’m also unsure if the fact that the Anker S330 is a combined speaker/mic combo unit is causing issues at the OS level on the satellite RPi. It just seems very peculiar that all playback and capture audio works perfectly from the Rhasspy HomeAssistant addon.

Any help would be immensely appreciated. Thank you.

I had so many problems with the S3 on linux that Anker gave me a full refund and they where really great about as it had weird effects such as playback would take time to wake on Linux and miss short notifications whilst on windows it was perfect.

It might be your settings but it could be the S330 but maybe on that model and newer firmware its all fixed.

Alsa pcms unless setup with a dmix/dsnoop shared IPC are single use blocking so if the container is running it will have sole use.

If you read through that it has examples and fixes and how to share /etc/asound.conf into the container and also how to create the IPC and Perms.

1 Like

Thanks for your response! That’s unfortunate about your experience with the S330. May I ask how long ago you tried it? I just picked up two of them, and as stated in my original post, it seems to be rock solid when picking up and playing audio from within the HAOS Rhasspy add-on, although I have not set up any intent processing yet until I get the standalone satellite Rhasspy RPi working with the S330.

To circumvent the endless arecord: main:830: audio open error: No such file or directory error messages, I finally ended up installing PulseAudio on the host, and the error stopped appearing, and I was able to issue an arecord command. However, no audio seems to be recorded (but playback via aplay still works 100% of the time).

I verified that my asound.conf file matched what was used on the HAOS Rhasspy setup, since the latter is working. It looks like everything is routed through Pulseaudio:

pcm.!default {
    type pulse
    hint.description "Default Audio Device"
}
ctl.!default {
    type pulse
}

When I did a docker exec -it rhasspy /bin/bash to get inside the Rhasspy Docker container and was looking around, I realized PulseAudio didn’t appear to be installed:

:/# arecord -Dpulse -f cd test.wav
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

Which lead me to rhasspy/examples/docker-compose-pulseaudio at master · rhasspy/rhasspy · GitHub, explaining how to connect the Docker container to the host’s PulseAudio installation. I’m not sure if this is going to fix the issue, since I still can’t record from the host.

Thanks for the reference to the forum post about playing audio through the host and the container simultaneously. I read through it and I’m not sure it applies to my situation, since I’m still not able to pick up any audio from the S330 on the host.

I guess I’ll check and see if Anker has any firmware updates for the S330. It just doesn’t make sense how the S330 can work so well in HAOS Rhasspy, with more limited configuration options, but on a standalone setup where I have much more fine-grained control over the config, recording still won’t function.

Mine was the original powerconf s3? So maybe not the same.

Yeah the will make pulse audio the default but pulseaudio wants dbus and doesn’t work well in docker so wouldn’t be surprised.

Because unless you have a dsnoop or dmix setup correct then alsa pcms are single use blocking so all you need is direct access in one place and it will block the rest.

pcm.!default means that would be the default so you don’t have to specify -Dpulse.

To break things down and just test out your Ankor (ps you a commdore 64 fanatic, them where the days :slight_smile: )
Get a spare sdcard with a clean install and just install rhasspy docker and set up with sharing /etc/asound.cond as you do need the same IPC keys for the same device but all devices must be different.
You have to add the ipc=host or whatever it is and the -v /etc/asound.conf:/etc/asound.conf.
docker container ls -a and stop and delete the rhasspy container and run the docker run with the ammends from the thread I mentioned.

docker -it <container-id> /bin/bash to ssh into the conatiner and because its default you should be able to just do speaker-test and get that white noise thing going on both host and container at the same time.

Once you have the /etc/asound.conf setting the default you only need to use default for all configs.

docker run -d -p 12101:12101 \
    --ipc=host \
    --name rhasspy \
    --restart unless-stopped \
    -v "$HOME/.config/rhasspy/profiles:/profiles" \
    -v "/etc/asound.conf:/etc/asound.conf:ro" \
    -v "/etc/localtime:/etc/localtime:ro" \
    --device /dev/snd:/dev/snd \
    rhasspy/rhasspy \
    --user-profiles /profiles \
    --profile en
# The IPC key of dmix or dsnoop plugin must be unique
# If 555555 or 666666 is used by other processes, use another one


# use samplerate to resample as speexdsp resample is bad
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
    ipc_perm 0666
}

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

If you mangle the above to your card and test you just swap out to your card name or id "hw:seeed2micvoicec"
PS
# use samplerate to resample as speexdsp resample is bad defaults.pcm.rate_converter "samplerate"
Is by respeaker and haven’t foggiest to what they are on about it just uses a resampler with double the load of the default and for me I comment it out.

I don’t know hass or even if you can edit the docker runs as with the docker rhasspy install it does have the critical --device /dev/snd:/dev/snd but also needs a few addtions to work correctly listed above.

If you get that far and it works and you have a known good it will prob make more sense when you try to install is Hass.

1 Like

Thank you!! And yes, I actually have my old C64 set up right beside my modern PC, complete with 1702 monitor, and a networked Ultimate 1541-II+ cart so I can just FTP software right to it. You’re right, those days were pretty amazing!

So as a preliminary test, before making any Docker changes, to see if I could get recording working on the host, I changed the host’s asound.conf to:

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:CARD=S330,DEV=0"
    ipc_key 555555
    ipc_perm 0666
}

pcm.array {
    type dsnoop
    slave {
        pcm "plughw:CARD=S330,DEV=0"
        channels 1
    }
    ipc_key 666666
    ipc_perm 0666
}

As you can see, I updated it to use the PCMs specific to the S330. Playback again works great with this, but now I’m getting dsnoop errors in arecord:

pi@rhasspypi:~ $ arecord -f cd test.wav
ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:830: audio open error: No such file or directory

Would you happen to have any ideas on how to get dsnoop working here? I’ve tried researching the error message but can’t find anything conclusive yet.

I believe I’ve found the problem using strace arecord test.wav. Looks like it’s an issue accessing this /dev/snd/ file:

openat(AT_FDCWD, "/dev/snd/pcmC1D0c", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)
close(3)                                = 0
write(2, "arecord: main:830: ", 19arecord: main:830: )     = 19
write(2, "audio open error: No such file o"..., 43audio open error: No such file or directory) = 43

This is still happening, even after I did a fresh write of RPi OS 64 to the SD card and installed libasound2-plugins. That was all I set up before testing arecord again.

did you try hw rather than plughw on the dsnoop. hw is hardware direct, whilst plughw does auto conversion, so its pcm "hw:*
Also try the id hw:x also

I think you need to use a hw: pcm if you don’t setup all the period timings rate and channels and stuff as via hardware it can pull that direct, plughw supply all the rest, but the plug higher in the chain will do conversion but 16khz is prob supported.
If 16Khz isn’t supported you can set supported values in the slave as the outside plug will autoconvert.

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

I have forgot totally what sample rates and channels it supports but its just the same as any usb device.
Alsa has such a strange format and poor documentation that I always end up testing and editing the pcms several times before I get it right but the above is from a working setup and all I can see is you changed from hw: to plughw on the dsnoop, where the only thing you may of needed to change is the channels.

A little util I often install is https://www.volkerschatz.com/noise/alsacap.tgz just make / sudo make install

Yeah would seem 16Khz so it should just pass on that rate without need to define its prob single channel as the diff between the s3 and s330 is the s3 had 6 mics whilst the s330 has 4 that likely beamforms to mono so channels=1, but you may find like me that a conference mic is totally different to how a smart assistant mic works.
Anker where great and gave me a refund as I was an early adopter using Linux and I spent some time answering questions to there tech support.
They sent me out a Powerconf C300 Webcam free and asked the same to try on linux.
The webcam because its designed to focus on user and pan is absolutely amazing compared the the conference type speaker mic as a high proportion of domestic noise is media and your conference mic will just focus on the loudest noise it thinks is voice and often that isn’t you.

Google has a short enrollment where it collects your voice and does something called targetted voice extraction and it stays focussed on you, that I think is part of the KWS and part of its local processing but that is just guess work.
A smart assistant mic and a conference mic are very different things and none really makes a smart assitant mic apart from those who make smart assitants, but by chance of testing the beamforming Webcam mics or built in tablet mic arrays work much better as the single user focus design is much closer to a smart assistant mic than a conference mic.
It will work when you eventually get the asound.conf right but its not really rigged up to cope with common forms of domestic media noise, but is great at removing constant background workplace noise which is a very different environment.

1 Like

Thank you! I actually got everything working now! I can record and play back audio now from the CLI!

I haven’t used Linux in about 20 years, so I’m a bit rusty, but all it took was some OS and package updates! It looked like some ALSA files were missing from some locale folders for some reason, after examining the strace arecord output.

For future reference, if anyone else is having similar issues, remember to do the following right after installing the RPi OS to your Pi:

sudo apt update
sudo apt upgrade

I’m now continuing on with @rolyan_trauts’s very helpful and detailed instructions on making sure asound.conf has the correct settings for Rhasspy. Thank you again!

1 Like

Great news !

I just setup a RasPi to run CloudCutter for some Tuya devices, and was surprised at the amount of updates for the latest RasPi OS - or maybe that they haven’t done a OS release for so long :wink:

One question - are you using the RasPi OS LITE or Desktop version ? From memory, I believe the desktop changes several things, including the way audio works by adding pulseaudio.

1 Like

Oh apols as yeah always on a new install update/upgrade also as donburch says don’t use the desktop version as it will just fill up with unnecessary bloat and likely confuse even more.
Also always pick the 64bit Lite version as all ML nowadays is heavily SIMD reliant and 32 bit will just halve the number of operations the Arm Neon will make with a single data instruction.
64bit Lite all the way unless you are using a ZeroW or have a Pi1 from somewhere.

In the RaspberryPiImager software its in RaspberryPiOther.

I am pretty sure the S330 is likely a different chip or upgraded over the S3 original and hopefully much better as mine is gathering dust.

1 Like

I’m using the Lite variant!

Yep, the S330 is now working solidly on both of my RPis. Must be a different/better chip than the old S3, like you said. And I did install the 64-bit version of the RPi Lite OS as well!

2 Likes

PS I took a closer look as it has been some time and with my specs on the model I had was the Powerconf, which makes sense as it was the 1st one they released.
So the S3 is prob OK and maybe I should plug mine back in and see if there is a firmware upgrade.

I think probably the S330 is prob the cheapest ready made off the shelf, plug and play solution.
The original powerconf was double the price of the S330.

1 Like

Oh, cool! Please keep us posted on how that goes–hopefully the S3 works great now for you. I’d like to set up more Rhasspy satellites eventually and it’s good to have mic/speaker combo options!

I am going to let it gather dust to be honest even on windows for me it performance was pretty medicore.
Its alright for an off the shelf solution but still pretty poor in comparison to say a full size Echo or Google Audio.
My main use for a ‘Smart Assistant’ is Spotify and listening to music on a speakerphone, its just lacks that bit of audio depth and is even short of the smaller commercial smart assistants whilst the mic/speaker costs more than the larger fuller bodied audio units.

I got one when I was trying to work out alternatives but think I have better solutions as if you are going to have a maker project then you at least want to try and improve on Commercial product or at least provide that artisan maker quality that they can not provide.

Even with the deals on the S330 of 39% off my preference would be to get a pair of 2nd user nice bookshelf speakers off ebay for £20 -£30 and because I am an audio snob Sure Electronics do these really great Amp boards for about £35 that yeah prob I could get much cheaper.
There are software algs and some laterial thought to engineering that if you stop just trying to copy commercial units and concentrate on a solution you can recycle ewaste and create an extremely capable modern room AV/Wireless audio/smart assistant system.
I have been an audio snob as there are cheaper amp boards but the biggest noise problem in a residential situation is third party noise via media such as HiFi & TV and I can intergrate that at low cost that is not much difference to your spend even with my snobby audio choice so I have total control and also make it sound great.

1 Like