Re: Sound support for Hurd and shortfalls of ALSA

[Damien Zammit]

On 29/6/20 7:52 pm, Ricardo Wurmus wrote:
> What is the API provided to user applications?  Or would it be enough to
> add support for this new API to JACK, so that all audio applications
> using JACK automatically benefit from this?

I'm not sure if it may be best to use the NetBSD implementation of SunOS audio 
stack,
with some modifications to provide sub-sample accurate buffer pointer,
via a userspace rump interface. This would allow JACK to run as it already has 
Sun audio support.
But would it be a really good design?

I am suggesting we do put the audio driver stack completely in userspace,
but with a completely redesigned server API (that can be implemented as a JACK 
backend so
we maintain JACK application compatibility).  We need to start from the audio 
driver side,
and we can because we are not restricted by what ALSA provides.

> Enthusiastic implementation in the Hurd is unlikely if adoption required
> active support from audio application developers.

I don't want to reinvent more inferior wheels, but Paul Davis 
(linuxaudiosystems) has said
that the biggest problem with audio on GNU/Linux is that there is no single 
unified
API for using the audio subsystem that all user applications use.
We need a pull model at the lowest level just like the drm video subsystem, 
kind of like
a framebuffer interface for audio.
Can you imagine trying to use the video subsystem via "open()", "read()" and 
"write()" calls?
In Paul's words, "... We don't do this for video, why do we do it for audio?"
I need help to design this, I don't have all the know-how by myself.
But if we have the right design, I'm sure we can move forward to create 
something wonderful
for audio on GNU/Hurd.  

A summary from Paul's 2009 slides includes as a suggestion for the server API:

>>>
    Formulating a server API that handles:

    - Data format, including sample rate
    - Signal routing
    - Start/stop
    - Latency inquiries
    - Synchronization
    - A server daemon that handles device interaction

    Details of timing considerations:

    - Capture and communication of best-possible timestamps of sound buffer 
positions
    - Communication of the latency/buffering sizes to userspace
    - Driver <-> userspace audio communication (e.g. an "audio framebuffer" 
interface instead of read()/write())
    - Communicating audio data
    - Communicating timing information
    - Communicating control flow
<<<

Damien