Subject: Re: Proposal: porting ALSA to NetBSD.
To: Jared D. McNeill <jmcneill@invisible.ca>
From: Andrew Nesbit <alnesbit@students.cs.mu.OZ.AU>
List: tech-kern
Date: 03/28/2002 01:44:34
On 27 Mar 2002, Jared D. McNeill wrote:
> On Wed, 2002-03-27 at 00:42, Andrew Nesbit wrote:
>
> > Would there be much interest here in having an ALSA port? I believe
> > that having ALSA working on BSD might get the ball rolling in getting
> > more audio apps and APIs ported to BSD, and possibly even seeing BSD
> > taken seriously as a platform on which to do digital audio work. I
> > think this would be good.
>
> It's not really worth it, if you ask me. Our sound drivers are on par
> with (if not better than) the ALSA drivers.
For sure about the drivers. But then there's the API. A big part of
my idea was to be able to easily port Linux audio apps to NetBSD.
Developers are moving away from OSS/Free now, and moving to ALSA for
an audio output driver, and also having support for LADSPA plugins,
etc. I think it would be great if we could easily get ports of their
programs.
Now that I've been thinking about it a bit, I think it should be
possible to do this by porting or implementing just the ALSA library
API and having it access the hardware using NetBSD's native interface
described in audio(4). If this arrangement were taken, then no ALSA
code needs to go into the kernel or LKMs: it could all be contained in
a package.
I think this might work because well-written ALSA-using programs
should only be using the ALSA library API (in theory, at least)... and
not the kernel API or anything low-level like that. I'll have to
confirm this with the ALSA people though.
So that's for the API... drivers are a different matter though. I'll
have a bit more of a think about it.
> It might serve useful to have a /dev/dsp that supports the ALSA ioctls,
> but that wouldn't require a direct port so much as a compatibility
> layer.
Could you please tell me a little more?
> Your efforts would probably be better spent elsewhere -- I can think of
> a few limitations of our audio subsystem that need fixing :^)
Thanks for the comments. I'm aware of the sorts of limitations with
NetBSD's audio subsystem, and I'd be helping fix them anyway if I
decide to go ahead with the plan I've jsut described. I need to
consider this a bit further though ;-)
-Andrew