Subject: Re: Ideas on the audio framework
To: Jukka Marin <firstname.lastname@example.org>
From: None <email@example.com>
Date: 12/12/2004 12:03:34
Content-Type: text/plain; charset=us-ascii
On Sun, Dec 12, 2004 at 11:11:23AM +0200, Jukka Marin wrote:
> > It seems to me that a kernel
> > volume API that both scales and provides ++volume, --volume is necessar=
> > more complicated than one that lets you adjust the volume between
> > [0, hwmax].
> I don't need to know the size of a hard disk to be able to write a file to
> it. Why doesn't the audio driver hide volume control details?
I fail to see how it relates to hard drives.
> > I think we can afford the overhead for audio applications that want to
> > scale to compute (app_volume * hwmax) / APP_VOLUME_MAX, don't you?
> Give xmmix a try and you'll know why I dislike the way NetBSD works at the
> moment. Besides the fact that I stills strongly believe it is the very
> purpose of the audio drivers to make the various audio hardware look the
> same to the application programs. I still don't know how other unix clon=
> work, but I'm 99% certain they do NOT work the way NetBSD does.
Linux and FreeBSD have stateful mixers, which means OSS applications (I
think ALSA is just the same for that matter) use the mixer as they
Our API is not OSS, and our mixers are stateless, and the OSS API
doesn't provide any mean of making the mixer appear stateless to the
Making our API stateful is quite a big change and should be done
properly (personnaly I'd favor some kind of registration of the mixers
to the audio(9) layer, instead of making each mixer stateful and keeping
the API as it is).
Or we could drop COMPAT_OSSAUDIO :)
Quentin Garnier - firstname.lastname@example.org - cube@NetBSD.org
"Commala-come-five! / Even when the shadows rise!
To see the world and walk the world / Makes ya glad to be alive."
Susannah's Song, The Dark Tower VI, Stephen King, 2004.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----