As it looks to me, most microphones are abandoned and there are no drivers that support current operating systems.
For example the Matrix Voice drivers are not available for Rasbian OS Bullseye.
Would it be possible to have a Docker container running Rasbian OS Buster and the microphone drivers and then access the sound card from the host OS?
That way we could use our hardware with the current OS.
I have limited experience with Docker and am not sure if it is possible to access the hardware from inside a container this way.
Ideas are welcome!
Yeah but much often seems to be missing.
The docker run normally is
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
So devices are shared via -device /dev/snd:/dev/snd but if even libasound2 libasound2-plugins
and drivers might not be, so dunno.
There are 2 docker commands and 1 bit of knowledge to know and then working with docker is just like a host.
To ‘ssh’ into the container which you have to think of as a totally different system its just docker exec -it <running_container_name_or_id> \bin\bash
You will be root user of the container and why docker requires sudo.
Then you can install just as you would on the host but the gotcha is containers are ephemeral and when you restart they return to the original image state.
So you have to commit that container to a new image after changes and all those changes will be committed into the new image and then change the docker run command to run the new image and not --name rhasspy
Alsa works perfect in a container if installed.
amixer -c1 contents
list current settings of card1 aplay -l
to list cards
amixer -c1 cset numid=3 1
alsactl -c1 store
save state for reboots.
Google docker commit and find a howto - example than just a reference as there are many
Once in a container its just the same as any system… apt-get
You need to make changes permanent and docker commit
to a new image
PS and I have tried to tell debian and not sure why as the rc1 of speex and speexdsp is ancient but debian installs rc1 whilst Alsa for nearly a decade expects the standard release candidate.
There is a hugely important plugin from speex (AGC) that for cards without AGC or many with poor AGC and volume it can be a life saver but it will be missing from libasound2-plugins as the wrong version of speex is installed.
I have rhasspy running in docker from the start. That works perfectly!
But is it possible to have the drivers for the mic running in a container as well? Preferably in a separate container so they are bundled with a compatible (old) operating system.
Containers are totally isolated from host and other containers drivers and software has to be installed into the container you are running by 1st sharing the devices which is already done.
You would 1st docker exec -it <running_container_name_or_id> \bin\bash
so you are in the conatiner.
Install the driver as you would on the host and even if it is already on the host as they are totally isolated and seperate systems
docker ps
or docker container ls
and after a couple of minutes of docker frustration you should pretty much have docker cracked as that is about it.
You have to make those changes persistent by committing to a new image.
Will show you how to enable speex plugins as teh agc is pretty important but a pain to recompile, but if needed.
Yes, that’s the point that’s confusing me.
In which way have the drivers inside the container access to the hardware of the host system?
How does the host system get access to the services provided by the drivers inside the container?
If you look at the docker run
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
There are 2 types of share there -v ‘volume’ where the host dir “$HOME/.config/rhasspy/profiles” the “:” is what seperates host and container sides is mounted in the container as “/profiles”
Same with “/etc/localtime” as shared as “/etc/localtime:ro” but readonly in the container
With devices and in this case sound --device /dev/snd:/dev/snd is again shared as --device /dev/snd:/dev/snd so the container has the device but no drivers unless part of the kernel drivers.
In this case the drivers are running on the host and can - of course - access the hardware.
Rhasspy is running in the container and uses the shared device file.
I wonder if it’s possible to have the mic drivers running inside another docker container (based on raspbian buster) and deliver service to the outside os (and the rhasspy-container) via /dev/snd.
You need to enter the container
docker exec -it <running_container_name_or_id> \bin\bash
Install the driver
then commit as a new image and run that one instead
Ah! The key point is “–privileged”.
I tried yummygooey/raspbian-buster and tianon/raspbian:buster but i always end up with something like:
# apt install matrixio-kernel-modules
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
matrixio-kernel-modules : Depends: matrixio-creator-init but it is not going to be installed
Depends: raspberrypi-kernel-headers but it is not installable
Depends: raspberrypi-kernel but it is not installable
E: Unable to correct problems, you have held broken packages.
Looks like raspberrypi-kernel and the -headers are neccessary but not included in the image.
Can this be fixed?
Install them is it sudo apt-get install raspberrypi-kernel-headers
from memory?
Maybe its just a debian docker image and the matrix drivers are hardcoded for raspios, oh well apols but nope.
If I run a raspian image in docker
root@caaaa869f15b:/# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
or
root@1f4fe2b94032:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
as its been set up as raspbian with the repo’s
deb [signed-by=/usr/share/keyrings/raspberrypi.gpg] http://archive.raspberrypi.org/debian/ bullseye main
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src [signed-by=/usr/share/keyrings/raspberrypi.gpg] http://archive.raspberrypi.org/debian/ bullseye main
apt-cache search raspberrypi
firmware-brcm80211 - Binary firmware for Broadcom/Cypress 802.11 wireless cards
libraspberrypi-bin - Miscellaneous Raspberry Pi utilities
libraspberrypi-bin-dbgsym - debug symbols for libraspberrypi-bin
libraspberrypi-dev - Libraries for the Raspberry Pi's VideoCore IV (headers)
libraspberrypi-doc - Libraries for the Raspberry Pi's VideoCore IV (docs)
libraspberrypi0 - Libraries for the Raspberry Pi's VideoCore IV
libraspberrypi0-dbgsym - debug symbols for libraspberrypi0
raspberrypi-archive-keyring - GnuPG archive keys of the Raspberry Pi OS archive
raspberrypi-bootloader - Raspberry Pi bootloader
raspberrypi-kernel - Raspberry Pi bootloader
raspberrypi-kernel-headers - Header files for the Raspberry Pi Linux kernel
raspberrypi-net-mods - Network configuration for the Raspberry Pi UI
raspberrypi-sys-mods - System tweaks for the Raspberry Pi
raspberrypi-ui-mods - Config to customise the LXDE UI for the Raspberry Pi
If it was that way then guess there would be no prob, why with so much specific hardware it is otherwise …
Which docker image are you using?
tianon/raspbian:buster is missing most of these packages:
# apt-cache search raspberrypi
linux-image-4.9.0-6-rpi - Linux 4.9 for RaspberryPI
linux-image-4.9.0-6-rpi2 - Linux 4.9 for RaspberryPI2
linux-image-rpi - Linux for RaspberryPI (meta-package)
linux-image-rpi2 - Linux for RaspberryPI2 (meta-package)
Installing kernel-headers fails:
# apt-get install raspberrypi-kernel-headers
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package raspberrypi-kernel-headers is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'raspberrypi-kernel-headers' has no installation candidate
I don’t as far too bemused
Try one of these
rhasspy64.tar
docker load < rasspy64.tar
docker load < rhasspy32.tar
Then change the docker run and run instead and see if kernel and drivers install
Or try yourself
docker cp raspberrypi.gpg container_id:/usr/share/keyrings/raspberrypi.gpg
docker cp raspbian.gpg container_id:/usr/share/keyrings/raspbian.gpg
nano /etc/apt/sources.list.d/raspberry.list and paste
deb [signed-by=/usr/share/keyrings/raspberrypi.gpg] http://archive.raspberrypi.org/debian/ bullseye main
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src [signed-by=/usr/share/keyrings/raspberrypi.gpg] http://archive.raspberrypi.org/debian/ bullseye main
if bullseye or change for buster
then apt-get update and try installing
if apt gives you errors about cache/…/partial cd to the root and cd up until you find the mising dirs and mkdir
then apt will works dunno why it was deleted apt-get clean
does the job…
after commits or loads change docker run
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
so change rhasspy/rhasspy to the new image name to run and try on installing you will likely have to commit and run that new image to load the driver on start.
So, i understand, you installed the matrix-voice driver directly inside the rhasspy container?
Mine (“rhasspy/rhasspy” - the official one) is based on Debian:
# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
Whereas Device Setup MATRIX and Microphones MATRIX require " the latest version of rasbian installed" .
I’d prefer to have a separate container to freeze the matrix-voice drivers.
Else, as soon as Rhasspy gets updated, i’d run in trouble again.
Does that mean, you have a Raspian-Buster-based Docker-Container serving Rhasspy?
Did you build that on your own?
Without Rhasspy it could be a useful basis for a matrix-voice-container. Preferably Raspbian Lite (Buster).
As mentioned before i wasn’t able to install the drivers into the Raspbian Buster Images i tried so far.
Lols I wondered what you where doing, now it makes sense why you had that old image.
Actually thinking about it /dev/sound shares as a pcm and maybe you only need to install on a host as I totally got the wrong end of the stick to what you where doing.
My memory is really bad apols, your 1st op sent me on a bit of a curve ball as thinking about it what I was doing wouldn’t of worked if required.
Its only if they are userspace drivers you need them in the container which most are not.
That matrix voice and why many are not getting updates is people have finally cottoned on that they where half a product and just having multiple mics on a board is pretty pointless and sadly the matrix products are probably even worse than respeaker.
It was supposed to have beamforming and was never implemented, respeaker had some software based that they never continued.
But unless you co-ordinate and lock onto a voice even the usb ones are pretty useless as they act as conference microphones beaming to the most predominant voice and in the community very few have been honest about this whilst others likely had vested interests.
Its sort of embarrassing as a series of hobbyist failed mic ewaste was sold to duped customer whilst various frameworks remained silent not wanting to mention the reality.
In fact apart from me all else seemed to remain very quiet but I haven’t touched any hardware for over a year it could be approaching 2 now and apols as yeah I have got rusty hardware wise with docker.
I am also the only one to actually do a software beamformer but even then it has to be linked to KWS so it locks onto that command sentence or it will just beamform to any predominant noise.
A sound card will do or a $10 2 mic hat that you can get off ebay or aliexpress and many have been very quiet about that whilst snakeoil has been sold to many. They are not great but at least its not magic microphone snakeoil as there isn’t such a thing that bolts-on and they have to be integrated and are a component.
The truth of the matter is beamforming needs to be linked to KWS as VAD will pick up on any voice and also you really need AEC and why Mycroft finally invested in a hardware version by xmos, but don’t waste your money as I am not paying $400 for what big data can do for $50 to likely give you an evaluation its not very good.
There has been this snips gold-rush fervour and an awful lot of what you could say is plain BS.
I think also the Plugable USB Audio Adapter – Plugable Technologies might be 2 channel in also as it certainly looks so in the specs and when I inquired they ignored my question and told me yes it certainly does have 2 channel out, which might be just a continuation of BS. So I just purchased one as that seems to be the only way to find out and I may setup a museum of soundcards that I am now a proud owner.
As said apols about the bum steer and either get a 2mic or wait for amazon to deliver before I can say 2 channel or not.
The other thing that is missing is BSS Blind Source Seperation that can extract your voice out of noise and there is no alg for that. We have a OK (sort of sub par to commercial silicon) AEC and near everything that really is needed for incoming voice processing is missing in all opensource software and its not just a hardware fix as KWS is much more than just to start record as it is now as in commercial product that gives a wealth of info from direction, amplitude and to a BSS that its your voice and feeds those so they work optimally, which is all definitely absent.
The drivers will have to sit on the host and with you posting a 4.19 kernel version you can either run that on the host or take the stance its effectively obsolete.
synesthesiam who created and maintains all this does what he does with the webside and bringing together packages and is a single guy who needs to make ends meet and has invested an awful lot of time, so the relative silence is really understandable and certainly has never got in my way of speaking out to some of the blatant snakeoil on here.
Strangely we are entering a realm where certain ML models and hardware is becoming available and the lack of audio processing just needs the work.
The Pi from not being able to buy one to what I am waiting to be delivered for not much difference in cost to a Pi4 4gb has x3-4 processing power a GPU that will run Onnx and also a npu that will run Onnx acceleration even though those are still previews.
https://www.aliexpress.us/item/3256804755567494.html?gatewayAdapt=4itemAdapt
Very fresh but it can run models that are far more tolerant to noise and accurate, filters that are near RTXvoice quality and its a shame as the Pi4 comes very close but is just a tad short as its a deal breaker for some of the latest and greatest ml models to the scene.
The above has x3-4 cpu power than a Pi4, but its GPU with armNN is also about equivalent and its also got a 3 core 2 tops npu where 2 tops is just slightly short of what the cpu can do and x3.
So its a ML powerhouse and makes the Pi4 look very old as do some of the newer models and software to what has been done previously.