Comment 245 for bug 371897

(In reply to comment #138)

> > The truth is that the Wine ALSA layer drives ALSA hard. Much harder than
> > Pulseaudio's abstraction layer can ever provide. That generates an impedence
> > mismatch that results in skips and broken streams.
>
> So you're saying Wine can never provide a satisfactory pulse driver because of
> limitations of pulse? On this point, we are agreed.

You have to remember that Pulse might not be talking to Alsa at the back end. It might be talking to an Apple Airport or even another Windows machine. Therefore it can only offer an Alsa subset that is the lowest common denominator between Alsa and the native pulse capabilities.

Also by definition if you can't create a native Pulse driver, then operating through the abstraction layer would be worse because you lose access to native knobs and twiddles. An abstraction layer can't offer more than the native.

So again if your argument holds, then it holds for modifying the alsa driver to work with pulse. So it is not rational that the ALSA driver can be made to work with Pulse, but a Pulseaudio driver can never be constructed. That suggests there is more to your position than objective technical and logistical issues.

> So if it is possible (in code) to make the ALSA driver work nicer with
> pulse (apparently there has already been movement in this direction), then that
> is definitely the way to go.

If it is possible, and there are people to do the work, then it should be attempted. From my position 1.1.29 is a lot better than before, but we're still losing streams randomly. So there is a way to go there, but the improvement is to be congratulated for all involved.

I also have a great deal of sympathy for the maintenance argument. I may be worth examining the commonality between JACK, OSS, ALSA and Pulse to see if unification is possible. Then everything can be native with very little code and the maintenance overhead can be reduced.