On Tue, 22 Feb 2005, Jonathan Stone wrote:

> In message <Pine.OSF.4.58.0502221046340.7415@pegasus.cs.csubak.edu>,
> Dave writes:
> >
> >Is anyone still working on ALSA for NetBSD?  How far is it?  How much
> >needs to be done?
>
> I'm not meaing to be snotty here, but seriously: why?
>
> Our audio framework doesn't have the shortcomings of the prior Linux
> audio framework. So why would anyone work on ALSA for NetBSD in the
> first place?  In order to (re)use ALSA drivers developed for Linux?

What what I've been able to tell, it's roughly similar to the old OSS
framework.  Allowing only one descriptor at a time for reading and writing
the sound devices is a big handicap when it comes to game design.  SDL
lessens this somewhat, but is still a problem when you just want to
quickly and easily spew some stuff out the soundcard.

> Surely there'd be sufficient source-code differences due to
> differences in the surrounding kernels, bus I/O and DMA software
> architecture (or absence thereof) that a Linux driver would be only a
> guide for rewriting a NetBSD driver? (And for the same reasons, ALSA
> object-only vendor drivers for Linux wouldn't be of use for NetBSD?)
>
> Is there a compelling reason that I'm just not seeing?

There's a lot of stuff that expects ALSA.  For example, I'm trying to get
some midi stuff working on NetBSD.  The only freeware sequencer for
Unix-alike systems is lmuse and requires ALSA.  SpiralSynth Modular
requires ALSA.  Fluidsynth seems not to, but does odd things that NetBSD
doesn't really like.

What I really want isn't so much a port of ALSA to NetBSD, but an API
layer on top of NetBSD's.


-- 
David Griffith
dgriffi@cs.csubak.edu