Hello @dscheiba
FYI the fix to find JACK development files from Pipewire has been merged into develop and will also be included in 3.13.0 when released, so this shouldn’t be a problem soon. (Of course it still applies if you want to build 3.12, unfortunately).
1 Like
Thats great news to hear, thanks for the info 
Looking forward to 3.13!
So this definitely looks like it’s about having the right package installed. I’ve run apt-cache search pipewire to look for things to try and I’ve installed the likeliest looking candidates (many of them were already installed):
- pipewire-jack
- pipewire-audio-client-libraries
- pipewire-alsa
- libspa-0.2-jack
- libpipewire-0.3-common
- libpipewire-0.3-dev
- libpipewire-0.3-modules
- pipewire-bin
And still no good I’m afraid. The missing piece is a mystery.
Uhm, sorry for my mistake. I thought this is for Fedora (where pipewire has been used for a while), and I provided the package name for Fedora, not Ubuntu, my bad.
pipewire-jack should definitely be installed for this to work.
Looking at this thread again, and at Ubuntu – Details of source package pipewire in kinetic, I’d try installing libjack-jackd2-dev. I hope it won’t pull the full jack2 in.
… no need to apologise, this thread can serve to help people installing SC with Pipewire on various distros.
libjack-jackd2-dev does not pull in anything else, and I’ve just installed SC! Thank you to everyone that helped!
The server doesn’t start 
but I think that’s for another thread.
You don’t need to have a jackd2/jackdmp process running for pipewire to be working. There’s no need to manually start it. On fedora, it’s already started as a user service.
I meant the SC server won’t start, not the JACK server.
Could I have a look at the dockerfile ? Usually I do a -DCMAKE_BUILD_TYPE=Release just in case there’s an optimisation that makes everything run faster, since it doesn’t need debug symbols in there if it’s for performances only.
Here you go Right now I don’t give so much about optimization but instead more on verbosity, but maybe there are ways to make it run a bit faster?
FROM alpine:3.15
ARG MAKE_JOBS=8
WORKDIR /root
# needed for pipewire
ENV XDG_RUNTIME_DIR='/root'
# although we will use pipewire instead of jack we need the
# header bindings which are not available for pipewire-jack
# so we will instead compile against native jack but replace it
# later
RUN apk add \
jack \
jack-dev \
git \
vim
# ------------------ SUPERCOLLIDER
RUN apk add \
alsa-lib-dev \
boost-dev \
boost-static \
cmake \
eudev-dev \
fftw-dev \
libsndfile-dev \
libxt-dev \
linux-headers \
ncurses-dev \
portaudio-dev \
readline-dev \
samurai \
yaml-cpp-dev \
g++ \
make
# apply submodule fix
# see https://github.com/supercollider/supercollider/issues/5695#issuecomment-1072263846
RUN git clone \
--depth 1 \
--branch 3.12 \
https://github.com/SuperCollider/SuperCollider.git && \
cd SuperCollider && \
sed -i "s|git://|https://|g" .gitmodules && \
git submodule update --init --recursive && \
mkdir -p /root/SuperCollider/build
WORKDIR /root/SuperCollider
# apply patch for alpine, see
# https://github.com/supercollider/supercollider/issues/5197#issuecomment-1047188442
COPY sc-alpine.patch .
RUN apk add patch && patch < sc-alpine.patch
WORKDIR /root/SuperCollider/build
RUN cmake \
-DCMAKE_BUILD_TYPE=Debug \
-DSUPERNOVA=OFF \
-DSC_ED=OFF \
-DSC_EL=OFF \
-DSC_VIM=ON \
-DNATIVE=ON \
-DSC_IDE=OFF \
-DNO_X11=ON \
-DSC_ABLETON_LINK=OFF \
-DSC_QT=OFF .. && \
cmake --build . --config Debug --target all -j${MAKE_JOBS} && \
cmake --build . --config Debug --target install -j${MAKE_JOBS} && \
rm -rf /root/SuperCollider
# now we replace jack with pipewire which is more stable
# in a virtualized environment than jack which resulted
# in an unstable clock and dropouts
RUN apk del \
jack \
jack-dev
# ------------------ PIPEWIRE
RUN apk add \
pipewire \
pipewire-media-session \
pipewire-jack \
pipewire-tools
also check out
which I want to improve in the next days
Eventually shouldn’t the compiled files be synced to the host? Also shouldn’t the docker container be the same OS version as the host?
Only if you want to run the binary on your host machine (but I wouldn’t recommend this, it is pretty likely to run into segmentation faults). the goal here is to run supercollider in a virtualized environment which has advantages such as security, maintainability, portability and scalability
Isn’t there a problem with getting jack to interact, as well as with X? I know I had to mess around with the container passthrus for lxc when containerizing some audio apps. Also don’t you have to configure jack to use either an open port, or pass through a configured named pipe? I remember jack using an unnamed pipe and I had to figure out how to get the container to interact wit the host audio.
When you launch SC, use terminal and type “pw-jack scide”
please try.
I went back to just Alsa + jack, no pulseaudio, no pipewire. I’m trying to compare now.
I thought pipewire didn’t allow me to set everything jack would enable me to do. I could not even choose my sample rate and tweak the latency anymore with pipewire.
If there is a way and I’m just dumb, please guide me. I’d like to know. Show me the way.
on Arch i’m using:
https://wiki.archlinux.org/title/PipeWire
https://wiki.archlinux.org/title/WirePlumber
& qpwgraph for connections. everything works ok.
i still didnt try network audio but i think it’s possible also.
i didnt try to adjust latency but on 1st link there’s this suggestion:
PIPEWIRE_LATENCY="128/48000" *application*
1 Like
I was only able to use 1024/48000, even with access to a RME adi-2 that can do 768k…
It worked, I just could not change any configuration to anything else.
Maybe next versions will improve this, of at least document it.
1 Like