Re: [RFC] no native audio translator on Debian GNU/Hurd 0.9; design discussion for /hurd/audio

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]
> >
> >