jbra...@dismail.de, le ven. 18 oct. 2024 12:45:50 -0400, a ecrit: > * open_issues/audio.mdwn: new file based on some irc logs.
Applied, thanks! > --- > open_issues/audio.mdwn | 115 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 115 insertions(+) > create mode 100644 open_issues/audio.mdwn > > diff --git a/open_issues/audio.mdwn b/open_issues/audio.mdwn > new file mode 100644 > index 00000000..574b5f4e > --- /dev/null > +++ b/open_issues/audio.mdwn > @@ -0,0 +1,115 @@ > +[[!meta copyright="Copyright © 2024 Free Software Foundation, Inc."]] > + > +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable > +id="license" text="Permission is granted to copy, distribute and/or modify > this > +document under the terms of the GNU Free Documentation License, Version 1.2 > or > +any later version published by the Free Software Foundation; with no > Invariant > +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the > license > +is included in the section entitled [[GNU Free Documentation > +License|/fdl]]."]]"""]] > + > +[[!tag stable_URL]] > + > +[[!tag open_issue_hurd]] > + > +The Hurd currently does not have an audio framework or [[audio device > +drivers|hurd/rump/rumpsound]]. One option would be to port `ALSA` to > +the Hurd, but `ALSA` is suboptimal for a [[number of > +reasons|https://github.com/linuxaudio/Linux-Audio-Workgroup/wiki/Towards-Fixing-ALSA]]: > + > +* poor device enumeration. If you unplug a sound card and plug it in > + again, you could get a different card number. The same problem can > + happen when you reboot. > +* With `ALSA` you cannot use two sound cards as one virtual sound card > + with synced time clocks. > +* `ALSA` makes it difficult to use a low latency application like > + Ardour alongside a higher latency application, like a desktop > + environment's sound notifications. > +* `ALSA` encourages applications to control hardware directly using a > + push model, meaning that the application tries to decide when to > + play sound. The pull model is much better, in that the audio > + subsystem tells hardware when to play sound based on requests from > + applications. > +* `ALSA` has backwards support for `OSS`, which is an even worse API, > + which partially makes `ALSA` such a poor design. > + > +Pulseaudio and pipewire, which are built to support `ALSA`, have > +similiar problems. Our Hurd developer/audio-expert Damien Zammit > +believes that the Hurd sound subsystem should use the [[`JACK` > +daemon/API|https://logs.guix.gnu.org/hurd/2023-10-06.log]]. He is an > +audiophile, who wrote and maintains some [[`JACK` > +plugins|https://github.com/zamaudio/zam-plugins/releases]], and he > +also wrote [[native `JACK` support for Qubes > +OS|https://github.com/zamaudio/qubes-jack]]. Damien spoke to Paul > +Davis, who is the reason there is professional audio on Linux and the > +author of Ardour DAW and JACK. Paul suggested we write a new JACK > +backend directly with low level driver code, and hack on the driver > +code until it is working. Then we could see how to define an API to > +move the driver level code into a hurd translator. One potential > +issue is that JACK uses lots of POSIX `shem` that the hurd lacks, > +though a patch exists in Debian or in the tg tree. > + > +We would have to create a hurd-jack backend for the `jackd` daemon. If > +clients do not support the `JACK` API, then they can connect to the > +Hurd's running pipewire daemon that would forward all sound requests > +to the jackd daemon. We would have a hurd translator sitting on > +`/dev/snd` and use RPCs to create a hurdish API that implements all of > +the things that `jackd` needs. We would not use `ALSA`'s API > +anywhere, but `ALSA` only applications should be able to play sounds > +through pipewire. > + > +A sound card driver would expose a set of RPCs that jackd would need. > +We could implement that part ourselves, which would be the easy part. > +The difficult part is making the driver, so that `jackd` opens > +`/dev/snd` and calls the RPCs to control it. Audio will not flow > +through `/dev/snd`. Rather, a callback is registered with a pointer > +to some buffer. We would *NOT* move the audio data via Mach messages, > +because that would be too slow. Instead jackd would `mmap` the device > +buffer directly or use shared memory to a small ring-buffer. The > +audio driver would `mmap` the device buffer directly, and we would > +share that with the caller. > + > +The audio driver would start and stop the sound card. We just need to > +fill its buffer somehow. The audio driver would know when to do this. > +It would schedule a writer and a reader probably based on timers. The > +arrival of the audio IRQ tells you when the hw pointer is at the end > +of the cycle, but you don't just copy the buffer when this happens > +(like alsa does). You use the timestamps of arrival of the audio IRQs > +to calibrate a delay locked loop. At any time you want in between the > +audio irq, you can ask the question: where is the buffer pointer now? > + > +We would use some kind of timer interrupt to schedule the transfer > +when you want, depending on the requested latency. This all happens > +in the audio driver, but it is controlled by `jackd`, and the audio > +driver will call the callback provided by the user application. > + > +The audio driver basically writes and reads zeroes until you fill it > +with some audio data, and if the callback blocks for too long and > +cannot deliver the audio in time for the next cycle, the audio drops > +the frame and you get silence, unless the audio driver is in the same > +process as `jackd`. Somehow `jackd` gets access to a mmap-ed buffer. > +`jackd` handles all the routing between different audio applications > +by creating a process graph. > + > +[[rumpsound|hurd/rump/rumpsound]] has an audio driver, but it's based > +on SunOS and [[does not have many > +cards|https://logs.guix.gnu.org/hurd/2023-10-07.log]]. If rumpsound, > +does not give the Hurd many device drivers for sound cards, then we > +may be able to use `ALSA`'s well organizied low level functions that > +implement all the features of sound cards. We will need to implement > +a pcm streaming driver that calls into ALSA low level functions (it > +could be GPLv2). It's difficult to break out, so maybe we will just > +start with pci. Damien got a sound card in qemu with `-soundhw ac97`, > +and `linux/sound/pci/intel8x0.c` should support that. The tricky bit > +will be sending audio data from the driver to another proccess without > +`mach_msg ()`. We could possibly use a ring buffer. > + > +## irc logs > + > +[[https://logs.guix.gnu.org/hurd/2023-10-06.log|https://logs.guix.gnu.org/hurd/2023-10-06.log]] > + > +[[https://logs.guix.gnu.org/hurd/2023-10-07.log|https://logs.guix.gnu.org/hurd/2023-10-07.log]] > + > +[[https://logs.guix.gnu.org/hurd/2023-10-08.log|https://logs.guix.gnu.org/hurd/2023-10-08.log]] > + > + > -- > 2.45.2 > > -- Samuel <D> m'enfin, le 5 juillet, le mec vient visiter le labo... * D a marque d'une croix rouge le 5 juillet sur son agenda <y> niarc niarc niarc <D> cet homme va souffrir <B> c'est donc le 5 juillet qu'il meurt d'un accident de la route écrasé par un truck muni d'un pare buffle -+- #ens-mim - repaire de terroristes -+-
