IRC channel logs

<damo22>it seems like the benefits of having gdb in userspace to debug is reduced when we have bugs in gnumach because we have to debug the kernel as well

<damo22>is this a generic problem or does it seem amplified with microkernels?

<youpi>it's not amplified

<youpi>and it's simpler to debug something that is smaller

<damo22>i hope we are reaching a plateau in terms of finding new gnumach bugs, but every time i add a feature i feel like ive added a new class of bug :(

<nexussfan>i wonder how to compile rumpaudio

<youpi>adding code always leads to new bugs, yes

<youpi>that's why the general modern frenesy about creating new software and enriching it is just a way to get bugs

<rrq>and debugging tools are geared towards using the stack for computationla flow, and doesn't handle "message passing" as well

<damo22>nexussfan: im not a fan of OSS for audio, so i started porting snd-intel8x0 to jack

<damo22>i now have it compiled, but it wont link because i need to finish porting the alsa core

<nexussfan>I thought rumpaudio is pulseaudio?

<nexussfan>"PulseAudio-compatible"

<nexussfan>I'm trying to get it running... need to use this buildrump.sh thing

<damo22>no, rumpaudio uses sunos api from netbsd

<nexussfan>Oh

<damo22>but the thing robert millan did was to wrap that in an OSS layer

<damo22>i spoke with the creator of JACK, he said id be better off porting some thing in userspace to jack backend directly

<damo22>and i chose ALSA because i have added support for a number of cards there

<damo22>even though ALSA code is now becoming spaghetti, the core api was designed to be modular

<nexussfan>I might try to port sndio

<damo22>if you havent started yet, can you instead help with my ALSA porting effort?

<nexussfan>I haven't

<damo22>let me push what ive got

<damo22>nexussfan: https://code.zammit.org/damo22/jack1-hurd/src/branch/feat-intel8x0-hurdsound

<damo22>cd jack1/drivers/hurdsound/sound

<damo22>make

<damo22>it should compile all the .c files into .o files and try to link but fail on missing symbols

<damo22>the symbols missing are the functions we need to port from alsa core

<damo22>its really a simple structure of function pointers that is being compiled here

<damo22>to drive the card at a low level

<damo22>the files being compiled that i did not write myself are unmodified ALSA source files

<damo22>so we can glue it together

<damo22>but it may be even better to reimplement part of it so its simpler

<damo22>ie, we can keep the low level driver code for card specific detail but rewrite the alsa core functionality

<damo22>i just realised, maybe we could expose ALSA sound cards as a hurdish netfs of a directory tree with cards at top level, and inside each dir there are nodes with the raw mmap'd sound buffers and a control node that can have open() close() and ioctl() ?

<damo22>not ioctl, actually rpcs

<damo22>then the problem is reduced to a hurd problem

<damo22>ie, how to manage buffers and drive a DLL using the arrival of audio irqs

<damo22>and schedule samples to play at the right time

IRC channel logs

2026-03-08.log