On Wed, 27 Mar 2002, Jaromir Dolecek wrote:

> Andrew Nesbit wrote:
> > 1. Firstly, ALSA is under the GPL, and so a port could not be merged
> > into the source tree.  An LKM would be the only way around this.
> 
> I'm personally not interested in something usable as LKM only.
> I do not want any GPL'ed drivers in the tree.[*] [**]

I find the idea unpleasant too; I've decided that doing this is just
way too ugly.  I agree that it would be /much/ better just to keep
going with NetBSD's native sound drivers. 

>  
> > 2. Linux has its low-latency scheduling patches, and this is very
> > attractive for people doing real-time audio work.  How does NetBSD
> > compare here?
> 
> Any URL to what are these? Are they integrated into Linux kernel?

They are at http://www.zip.com.au/~akpm/linux/schedlat.html and no, I
don't think they have been integrated into the kernel.

> > 3. Would this actually be worthwhile from a practical point of view;
> > would it encourage people to use BSD for digital audio work, or is the
> > momentum in Linux just far too strong?
> 
> It's not like ALSA would be the only way to achieve good audio
> quality. We have fairly good drivers for many sound cards available today.
> Our audio interface is fairly sane, and quite compatible with Solaris/SunOS
> (with some extensions). It has some limitations, but some of these
> are going to be addressed in not-too-distant future.

Sure, I just thought it would be good to be able to make use of prior
work...  this is the first time I've had to grapple with these sorts
of licensing issues.  I'm beginning to understand how the GPL can
cause people problems ;-) 

> I think the efford would be better spent writing a userland glue
> library similar to libossaudio, to make eventual porting of programs
> using ALSA API easier.

Yes, I've decided that this would be the best way to go...

> It would be useful to analyze and summarize
> the features of ALSA API, and discuss possible good ideas here.

Well, the first thing I suppose is to look at the ALSA library API,
and also to look at the NetBSD audio subsystem, and try to deduce some
sort of "mapping" between them, taking into account the current and
proposed capabilities of NetBSD's audio subsystem.

And ideas for implementing the ALSA ioctls would be good too...

It's great that libossaudio already exists as a solid starting point
for these ideas.

I'll start on this tomorrow.

-Andrew