IRC channel logs
2023-12-30.log
back to list of logs
<damo22>maybe a hurd audio driver could expose a file node each for playback and capture virtual buffers, that can be mmap'd by the user. So the audio is mixed in at the right time by the driver into the hardware buffers <damo22>it could all be floating point at the point of entry, so the driver can handle sample rate conversion and format -> hw <damo22>pauls idea of writing a jack backend probably makes sense for a start <azert>damo22: I personally believe that Paul idea for the audio driver is a great one. While exposing the driver iterfaces on the filesystem is a cool idea and handy for virtualization, where the Hurd can shine is really to have complex drivers. That is not possible in Linux <azert>By linking the driver directly as a backhand to the Jack/pipewire stack, you potentially end up with better performances than linux <azert>This doesn’t exclude adding a Mach transport and clear interfaces through the file system. But the Unix pipes are probably good enough, and an iouring kind of interface would probably be better <azert>Btw iouring has been created as a meltdown mitigation to the mitigations, but has the potential of being a great way of doing ipc, what do you think about it? <ThinkT510>Isn't part of a microkernel's responsibility that a single driver cannot bring down the whole system. Linking drivers directly to an audio stack seems to be a bad idea. <azert>I see it more like the audio stack becomes the driver <azert>If it dies, the system can restart it <azert>In a way, it’s like Wayland on linux <ThinkT510>the whole audio stack? wouldn't that affect ALL applications using the audo stack? <azert>One have to design a protocol that can be restarted with minimal state loss <ThinkT510>you'd only need one faulty driver to cause complications for all applications <azert>That’s exactly the way Linux is going de facto <azert>And Linux is a shittier design to accomplish that then hurd <azert>Im arguing for embracing modernity