Klaus Heinz wrote:
> I remember some discussions on tech-kern (2002-03 / 2005-02 according to
> mail-index.NetBSD.org) about an ALSA-compatibility layer for NetBSD but

There are two broad components of ALSA that can perhaps be usefully
separated. One deals with sampled audio, the other with MIDI. It
might be possible and even worthwhile to treat them as completely
separate, i.e. COMPAT_ALSA_AUDIO and COMPAT_ALSA_MIDI.

For MIDI, the chief contribution of ALSA is a new in-kernel MIDI sequencer.
I believe we should emulate this, as it adds significant functionality
compared to our current (OSS-like) in-kernel seq. Rosegarden seems
positioned to be a killer app for composition and sequencing, and has
discontinued official support for anything but ALSA.

As opposed to sampled audio (a stream of samples in real time passing
as determined by the sample rate), a MIDI sequencer deals with a stream
of events (largely note-start and note-end) in virtual time, determined
by time stamps attached to events.  The necessary functions are:

A  multiplexor
   combine several independent streams of MIDI events, carrying tags
   for destination MIDI bus/channel and for intended timing, into a
   single stream ordered by time.
B  timed gate - from the single stream of ordered, tagged events,
   release no event before its time; the output stream contains MIDI
   events still tagged with bus/channel, the time tag stripped.
C  demultiplexor
   route the resulting events to the specified MIDI busses, events to
   each bus in standard MIDI form tagged only with the channel on that
   bus.

Our current in-kernel sequencer handles B and C; the userland app is
expected to present the single stream ordered by virtual time as in A.
ALSA moves the user/kernel boundary above A; so the ALSA seq can be
opened multiple times and does its own priority queueing. If a NetBSD
version uses a periodic interrupt for timing (which is the usual
approach), it may be able to build on the timing-wheel code already
used in the clock, and improve performance over the mechanism in ALSA.

(MIDI sequencers typically offer a choice of periodic timing source,
from a variety of devices present on the system that are capable of
generating one. This is an area where we fall short even of OSS; our
sequencer uses microtime and the callout facility exclusively, and
essentially reports success to any timebase-set operation requested
by the userland, regardless of how realistic it is to generate the
requested timebase from the HZ of the system clock.)

Finally, the destination MIDI busses that can be specified in an
ALSA sequencer stream do not need to be actual MIDI busses or
synths present on the system; user programs can create and register
virtual ports and have the sequencer demultiplex events to them too
at the scheduled time.

In contrast to the OSS sequencer with its fixed size event
structs, the ALSA sequencer uses various and variable sized
records, and therefore requires more involved memory management
in the kernel.

I'd be willing to mentor (or co-mentor with someone, as I'm a brand-
new NetBSD developer myself) someone interested in the MIDI portion
of ALSA. As we did with OSS, what we need first is not so much the
(better documented) library API, but the kernel ABI.

Now that I have a box running -current, I expect to commit my own
MIDI updates from the winter RSN, at least on a testing branch if
not to the trunk, so they can serve as a starting point.

-Chap