Here is my Gist talking through how to use NetJack2 to forward audio from SuperCollider inside a container to Jack running on the host.
I’m hoping that the README.md is sufficiently detailed. Any Linux users that want to try it out and let me know how it goes?
I’ve also had a weird intermittent XRUN issue. Sometimes when I start the NetJack2 session I get constant XRUNs at a rate of about 1 or 2 a second, other times it’s perfect. I’ve tried fiddling with the size of period and nperiod in Jack, but with intermittent issues like this it’s a complete pain to diagnose.
Anyway, feedback is appreciated, seeing as it works on my computer (most of the time), it would be good to know if it works elsewhere too.
Anyway, an updated method, this time using ALSA passthrough to the container. Essentially due to the way that containers work, the kernel is shared, including /dev/snd (i.e. ALSA).
It’s was a bit of a pain trying to figure the correct set of incantations to get it to work inside Docker (especially dealing with group ownership), but it does work, and it it gives native performance. The downside is that you have to dedicate a soundcard to it, and there is no hope for it working on OSX or in a VM.
This Gist gives a worked example of getting SuperCollider running inside a container with native performance, along with some technical info as to how it works.
I’ve also updated the first post with a summary.
Now that I have decent audio performance it’s time to actually get Norns running, plus the school holidays are about to finish so I might have some time!
I had to patch the yarn.lock file to deal with the DNS issues. It also looks like registry.yarnpkg.com is going away in the long run (yarnpkg/yarn#5891), but I’m not sure what we’re supposed to do about it.
All is not completely perfect as I’m getting seg faults in matron with some of the scripts, but on the plus side it will be very easy to gdb!
I’ll try to get a repo up this week (hopefully once Yarn have sorted their DNS issues), and then it will be time to start thinking about what direction to go in.
Some ideas to get everyone thinking:
reproducible dev environment, and what’s a good workflow
I’m going to try and put it up in a GitHub repo this week along with a proper README.md.
If I haven’t done it by next weekend feel free to harass me and I’ll get it in a Gist just to make sure that the info is out there.
edit: Got the grid working too! That was a little tricky, but essentially udev is a bit wonky inside the container, so I had to build libmonome to use sysfs instead.
edit 2: Added some notes to the first post with results from experimentation on OS X (i.e. couldn’t get NetJack2 in the Docker container to see the host)
edit 3: Added some notes about running gdb inside the container… now I just need to figure out this backtrace…
Matron backtrace
Thread 1 "matron" received signal SIGSEGV, Segmentation fault.
_screen_extents (l=0x563220a44638) at ../matron/src/weaver.c:737
737 lua_pushinteger(l, xy[0]);
(gdb) bt
#0 _screen_extents (l=0x563220a44638) at ../matron/src/weaver.c:737
#1 0x00007fd19d92c77e in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#2 0x00007fd19d939565 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#3 0x00007fd19d92cb6f in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#4 0x00007fd19d92cbc1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#5 0x00007fd19d92bf92 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#6 0x00007fd19d92ce4d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#7 0x00007fd19d9285c1 in lua_pcallk () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#8 0x000056321f87d0eb in docall (nres=0, narg=0, L=0x563220a44638) at ../matron/src/lua_eval.c:140
#9 l_docall (L=0x563220a44638, narg=narg@entry=0, nres=nres@entry=0) at ../matron/src/lua_eval.c:149
#10 0x000056321f883eb2 in w_handle_engine_loaded () at ../matron/src/weaver.c:1515
#11 0x000056321f87c673 in handle_event (ev=0x7fd1880062e0) at ../matron/src/events.c:236
#12 event_loop () at ../matron/src/events.c:158
#13 0x000056321f878fe9 in main (argc=<optimized out>, argv=<optimized out>) at ../matron/src/main.c:90
Still lots to be done. Expect some force pushes until things are stable. I’ll update the top post once we’re a little further along.
Also, the automated Docker hub builds are borked. I think it may be too much RAM usage from sc3-plugins, will try to get it to build -j1 and see if that fixes it.
I also found this rather interesting repo:
Could be useful for automating the building of images.
Thanks for the feedback. I’m hoping to get sound output working on OS X eventually, partly because sometimes I’m on my laptop which runs OS X, and partly as I think that will be the best way to get more contributors.
Yeah, I wasn’t entirely sure what the best way was at first. I really didn’t want to have to go down the route of a service manager like runit.
I think I had installed tmux into the container and was manually starting each component when I was testing it out, and just thought there must be a way to automate this… (it was highly tedious).
I think my next plan of attack is to try to hack maiden into opening an X11 window for screen output and key/enc input. I’m not planning on it being pretty, really just a proof on concept at first. That should also give me enough first hand experience to start writing a dev workflow guide.
The norns-image repo has the systemd unit files which are used on the actual device - that might be of use. There has been some talk of exposing the ability to restart crone and matron from within maiden so it might make sense to stay with systemd for compatibility reasons.
…ah yeah. I had forgotten that. The topic of packaging the norns software via snap or flatpak has come up on more than one occasion. The motivation is trying to improve the reliability of the update process and offer an easy way to fall back to an older version of the software if need be. Neither of those technologies play nice with docker unfortunately…
AFAIK Flatpak uses the same kind of technology as Docker. I reckon you can make either of them emulate the other to a certain degree.
Is Flatpak a container technology?
It can be, but it doesn’t have to be. Since a desktop application would require quite extensive changes in order to be usable when run inside a container you will likely see Flatpak mostly deployed as a convenient library bundling technology early on, with the sandboxing or containerization being phased in over time for most applications. In general though we try to avoid using the term container when speaking about Flatpak as it tends to cause comparisons with Docker and rkt, comparisons which quickly stop making technical sense due to the very different problem spaces these technologies try to address. And thus we prefer using the term sandboxing.
Arguably if you were going down this route, Docker or systemd-nspawn would be a better fit than Flatpak or Snap (and you could also argue the converse too).
I will say that Docker has a tendency to eat storage space if you’re not careful.
Anyone know what’s going on with this? Also I’d love some help getting it hooked up to alsa/jack on Arch. I’m gonna make a thread today but thought I’d mention it here, too.
Hi, I’d like to experiment with norns (it seems awesome) but currently I don’t have the funds to buy a norns or norns shield - however I do have a linux PC. As the norns software stack is open source (and can run on a raspberry pi) , is it possible to run norns software on a linux desktop PC? I know it’s a very different experience to run it on a PC vs hardware, and defeats some of the point - but I’d like to mess with norns before I invest (I don’t want to end up in an axoloti situation, buying a cool music device and having no cool use for it)
