Hm, I have this fancy new double-buffering architecture just because of tru64/mme which works, basically, but still bitches around so that I'm quite fed up with it.
Is it my fault when this audio server just cannot deliver smooth, continuous playback? When it just freezes a connection after a random time?

Whatever, through this I got a nicely working ALSA device. But what's not so nice is, that I broke the OSS!
Playback sounds weird with this double-buffering; it is jumpy, going too fast (ironically, this bug manifests better with faster machines and it took me a while to reckon it with my slow bugtesting machine).

So how come?

dermixd-1.0 did:

prepare audio
write to /dev/dsp
continue loop

dermixd-1.1-to-be-beta1 does:

prepare audio
wait for _last_ chunk
write audio
continue

The idea is still that the writer threads writes serially one buffer after another.
But when I ensure that play() waits for the semaphore before continuing, the playback is ok!
But I don't see the fundamental difference for /dev/dsp... 
I still write buffer, write buffer, ...
but with the double buffering there maybe a smaller delay between write attempts - but isn't oss supposed to block when the old playback is not finished? Somehow stuff gets overwritten...



First thoughts:

The output stuff needs restructuring. 

I want the general code to be in the general class. The special code in the special class.

What's really special: 

- (de)allocation / initialization of special variables
- activate() of device
- deactivate()
- writer thread function
- pause...?
- suspend...?

What's not special:

- logic of play()
- logic of load()

