[semi-OT] Re: portupgrade O(n^m)?

[Craig Boston]

On Thu, Feb 15, 2007 at 04:32:00PM -0800, youshi10 at u.washington.edu wrote:
> I just want to help make a great system even better--that's all; the only 
> parts of the system I can possibly thinking of improving that also align 
> with my interests are the ports system and sound system (daemonizing it 
> like ALSA [...] )

I for one much prefer the FreeBSD way of handling sound over the ALSA
method.

IMO, ALSA is overengineered and introduces unnecessary complexity into
the lives of both application designers and end users.

Take for example the task of playing multiple PCM streams simultaneously
on a device which supports only a single hardware channel (99% of
integrated sound chips).

ALSA:
	* Edit some config files to set up a virtual sound device
	  and force it to be "first" in the ordering.  If you're lucky
	  you're using a distro that has already done this for you.
	* The mixing happens in a userspace daemon, that you hope isn't
	  swapped out or accidentally killed.  Hope that the kernel
	  schedules it often enough to do its job.  Incur extra context
	  switching and IPC costs.
	* This only works for applications that use the ALSA API.
	  Others must be run under aoss or equivalent, which has the
	  same issues as esddsp and artsdsp (problematic mmap support,
	  for one)

FreeBSD:
	* sysctl hw.snd.maxautovchans=8

> instead of having stuff block /dev/dsp, /dev/mixer, like OSS

Enable vchans and it'll be just like having a sound card that can do
hardware mixing.  FreeBSD's sound API is compatible with OSS, but it by
no means has the same limitations as Linux's OSS implementation did.

I've never had any problems with contention over /dev/mixer, even when
using multiple applications that want to adjust the mixer settings...

The only advantage I can see ALSA having is MIDI support, which has
atrophied as of late in the FreeBSD world.  That's not really a product
of the architecture so much as not having enough interested developers.

Craig