-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
running Rhasspy3 (tutorial) in a docker container #7
Comments
The onnxruntime package exists for Alpine in the repo (https://pkgs.alpinelinux.org/package/edge/testing/x86_64/onnxruntime), but it's in edge, i.e. not stable branch. It means that it will require few dependent packages (including musl itself) to be switched to edge. Not sure we want that in terms of stability, but I can give it a try. I've also seen few traces of ppl building onnxruntime successfully from source - I even tried that myself following one of such guides, but it didn't work quite well in my case. But again, if we need it namely on alpine, I can put some better efforts into that. |
Is there an official docker yet? |
@NonaSuomy if you're interested I've made a simple sh script to create your own local docker image - it's just a one-click-thing and in a couple of minutes you have it. It's still WIP though, there're few missing parts (they're mentioned in TODO), but you can give it a try - https://github.com/kha84/R3Docker |
I run portainer with watchtower for updates so was hoping for a simple docker-compose linked to a GitHub to point it at so it can keep updating itself weekly as it gets better. |
It's not an issue, it's a side note!
Just in case, if anyone is interested to play with Rhasspy3 in a docker container (whatever your motivation is) - onnxruntime doesn't work quite well with Alpine-based containers, because of musl. So build your containers out of something different. In my case I'm running this on a top of my Ubuntu 22.10 with Pipewire as a sound server executed under my own user - thus the fd mount.
.... or just follow the rest guide - https://github.com/rhasspy/rhasspy3/blob/master/docs/tutorial.md
I'd like to thank @synesthesiam Michael once again, I followed his guide and everything works just perfectly.
Need to mention, if you're planning to run this on a headless system without being logged in to X all the time, Pipewire in the most of the popular distributions is configured to run under a user account and reconfiguring it to run as root is highly discouraged. So on most recent linuxes it works like this: before you log in, pipewire is executed under "gdm" user, if you're running Gnome with GDM. And then, after you login, the gdm's Pipewire is stopped and your own one is started instead.
I think, for such cases (headless system with some occasional interactive use), the ideal scenario here would be to reconfigure pipewire systemwide e.g. in /etc to accept local network connections and use them instead. So it doesn't matter if the gdm user will be running Pipewire, or your own user, docker container will be able to connect to it over TCP.
I spent quite a lot time, figuring out where the tail or head is in such "sound in docker using pure alsa" / "sound in docker when the host is running pipewire" / "sound in docker when the host running pulseaudio" configurations :)
The text was updated successfully, but these errors were encountered: