I don't know the answer to your first question because I haven't finished the proof of concept yet. But my intention is to have jack clients connect as is. And jackd to run in userspace. There may be a shm issue that needs to be resolved?
Your second question : its very incomplete at this point, I wanted to rewrite the core because ALSA has inherited too much unneeded bloat and the design of the streamer should not depend on the arrival of the irq to trigger the sample delivery. I want to use a DLL calibrated by the audio irqs to know where the hw pointers are at subsample accuracy and then schedule transfers on a hi res timer. This driver will be able to report latency correctly. This was Paul Davis' idea. Damien Sent from Proton Mail Android -------- Original Message -------- On 1/6/26 1:29 am, Borja Tarraso <[email protected]> wrote: > Hi Damien, > > > I was doing a proof of concept taking one alsa driver for intel > > pci card and making a jack backend for it so there should be no > > other userland requirements apart from using the jack api for > > sound. It needs work. > > https://code.zammit.org/damo22/jack1-hurd > > Read through the repo before replying. I see the active work is > on the `feat-intel8x0-hurdsound` branch (master is upstream JACK1 > maintenance only), four commits from January adding ALSA ac97 / > intel8x0 low-level code, a linux-headers shim, and finally a > dummy prober "to test linkage" with the CI check failing. That > gives me enough to know the shape and roughly where you are; I > will plan to build that branch against canonical Debian > GNU/Hurd 0.9 and use the QEMU intel8x0 / ac97 device as the > reproducer. > > Two questions before I start poking, so I do not waste your time > on the first round of test output: > > - On the jack side, what is the intended IPC shape? A > jack-server that binds against a Mach port and lets existing > libjack clients run unmodified, or does the client side also > need a hurd-flavoured shim because the AF_UNIX path libjack > uses today does not survive on pflocal? This decides whether > I run an unmodified jackd test client against your build or > expect to patch the client side first. > - On commit 960a814e90 the prober is marked Failed checks. Is > that a known stop (linkage proves out but the prober itself > is incomplete) or is the failure something you would > appreciate a second pair of eyes on before the next push? If > it is the former I will treat the branch as "build, do not > expect runtime yet" and report only what the build does. > > Side note: faq/audio.html still answers "Is audio supported?" > with "This is pending work" pointing only at rumpsound (last > updated 2026-02-06). If jack1-hurd reaches a testable state I > am happy to send a small FAQ patch adding a cross-link, so the > next person asking the question lands in the right place. > > Thanks, > Borja Tarraso > [email protected] > > El dom, 31 may 2026 a las 3:24, Damien Zammit (<[email protected]>) > escribió: > > > > I was doing a proof of concept taking one alsa driver for intel pci card > and making a jack backend for it so there should be no other userland > requirements apart from using the jack api for sound. It needs work. > > > > The experiment lives at https://code.zammit.org/damo22/jack1-hurd > > > > Thanks, > > Damien > > > > Sent from Proton Mail Android > > > > > > -------- Original Message -------- > > On 31/5/26 10:03 am, Borja Tarraso <[email protected]> wrote: > > > > > Hi NexusSfan, > > > > > > Thanks for the pointer. > > > > > > > This is already a thing. https://github.com/dm0-/hurd-rump-audio > > > > > > I went and read the repo. It is a useful proof of concept (the > > > "settrans /dev/audio + rump-AC97 + PulseAudio module" path I was > > > asking about under level-b is exactly the shape that lives there), > > > but the author's own README caveat is that it is "just a silly toy > > > program" and that the right next step is writing a proper > > > PulseAudio module instead of going through the rump translator. > > > The repo also has just the one commit and is not packaged for > > > hurd-amd64 in Debian apt, so as far as the canonical-image gap is > > > concerned the RFC's question still stands: what is the upstream > > > direction for a real /hurd/audio plus a backend that QEMU > > > intel-hda / ac97 can drive without each user reproducing dm0-'s > > > local rump build by hand? > > > > > > > I would much prefer sndio over ALSA or other audio interfaces, > > > > but some developers are working on ALSA for Hurd, I've heard. > > > > > > sndio matches the level-b sketch in the RFC; its IPC shape is the > > > small / readable one and it is the lowest-common-denominator API > > > that survives the Mach IPC boundary cleanly. Good to know it is > > > the preference among Hurd hackers as well, that is one less design > > > question. > > > > > > Do you know who is doing the ALSA-on-Hurd work, or where it is > > > tracked? Happy to coordinate with whoever it is so the two efforts > > > do not collide; if ALSA lands first I can pivot the userland side > > > accordingly. > > > > > > I am also filing in parallel on [email protected] for > > > the packaging side (bundle pulseaudio in the canonical image so > > > the apt-installed userland path comes up zero-config); the deeper > > > translator work stays in scope for this thread. > > > > > > Thanks, > > > Borja Tarraso > > > [email protected] > > > > > > >
