On Wed, Oct 10, 2007 at 06:22:19PM -0500, King InuYasha wrote:
While PulseAudio can work through ALSA, it makes you lose the finer grains of control over audio when it is sent through ALSA to PulseAudio.
Then it seems that is a limitation of the alsa plugin pulseaudio provides. Fixing that plugin would not only benefit Wine when it uses pulseaudio through alsa but every application which might do this. Implementing a winepulseaudio would only bring that benefit to Wine and it would have to be duplicated for every other alsa application which pulseaudio would want to support.
It is also redundant in most cases, since PulseAudio generally will be connected to localhost to ALSA on localhost, so it is not very smart to rely on winealsa to connect to PulseAudio.
Sending audio output through ALSA/OSS to any audio server is basically redundant and pointless. Sending to the Audio Server to ALSA/OSS is better.
I guess you didn't want to say that the audio is sent over ip. Though I don't know how pulseaudio does things specifically, I do know what is technically possible. Passing data from one process to another on the same computer can be done without copying the data. Also passing the data into the alsa library which passes it into the hardware or dmix or the pulseaudio plugin does not involve two steps as you seem to suggest, but only one. Yes alsa->pulseaudio is an additional layer but you could think of it as a replacement of pulsaudio-api->pulseaudio.
That way, there isn't a conflict between audio streams to send to audio output.
Any mixing resolves this conflict, the only thing that does not support this is bare oss.
Jan