Linux is not ready for Steam

[darkphoenix22]

You can implement sound-related features in a sound daemon, or in all kinds of different libraries/daemons. So, maybe Bluetooth drivers should take the relevant code from PA and put it in their own repository. Doesn't change a thing, but at least it isn't called PA.

At least it won't take over my entire sound system like PulseAudio.

[mugginz]

Why? It's what pairs and connects the devices. The mechanism that connects the Bluetooth audio device should make the Bluetooth audio device default.

Because ignoring smart architecting of the sound stack, this only deals with the bluetooth case, not the USB audio case.

[Remco]

At least it won't take over my entire sound system like PulseAudio.

Oh, but it would. It would just not be called PulseAudio. Instead, every part that has to do with audio implements largely the same functionality, and hits the same problems as PA did. Instead of being able to point to PA for making sound crap, you can now say that *everything* is crap.

[darkphoenix22]

I should add that bluetooth is one example of this functionality.

It applies equally well to a father at home listening to audio playback on his pc, and when his kids go to bed he can then plugin a USB headset and have the audio re-routed to that as just another example.

Then there's the cases when you're dealing with game audio playback where you might want to switch between your stereo and a headset.

I don't agree. It would be too hard to detect a USB headset at the driver level. Switching the output via the mixer is a much better solution. Much less overhead.

Again, this barely works on Windows.

[darkphoenix22]

Oh, but it would. It would just not be called PulseAudio. Instead, every part that has to do with audio implements largely the same functionality, and hits the same problems as PA did. Instead of being able to point to PA for making sound crap, you can now say that *everything* is crap.

Would it do this?

http://www.allegro.cc/forums/thread/600325

Taking over the devices is a BAD IDEA. Providing a separate mechanism to provide the audio switching functionality is a much better idea.

[mugginz]

I don't agree. It would be too hard to detect a USB headset at the driver level. Switching the output via the mixer is a much better solution. Much less overhead.

Again, this barely works on Windows.

Rubbish. You're suggesting that the ALSA USB audio driver should deal with the specificities of audio playback and sound server activities?

Perhaps I'm wrong but I thought you were calling to keep complexity out of the drivers.

[mugginz]

I don't agree. It would be too hard to detect a USB headset at the driver level. Switching the output via the mixer is a much better solution. Much less overhead.

Again, this barely works on Windows.

So you add the system autoconfiguration into the driver?

[darkphoenix22]

I'm calling for the Bluetooth drivers to provide the Bluetooth audio switching functionality.

[darkphoenix22]

So you add the system autoconfiguration into the driver?

To the mixer. Without requiring that applications pass the audio through the wrapper. The mixer should just regulate the connections.

[mugginz]

I'm calling for the Bluetooth drivers to provide the Bluetooth audio switching functionality.

The bluetooth driver should provide an interface to the audio hardware for the sake of code clenlyness.

The switching belongs in the sound server.