Basically, I'm calling for an audio libfuse.
Announcement
Collapse
No announcement yet.
Linux is not ready for Steam
Collapse
X
-
Originally posted by darkphoenix22 View PostTo the mixer. Without requiring that applications pass the audio through the wrapper. The mixer should just regulate the connections.
If you just want it provided by something that's not Pulse then that makes no sense. If it is required, it's required. No matter what you call the code.
Comment
-
Originally posted by mugginz View PostBut then the mixer is providing the same services as PulseAudio. See, you can't get around the need of that functionality.
If you just want it provided by something that's not Pulse then that makes no sense. If it is required, it's required. No matter what you call the code.
And the auto-routing should just use the plain ALSA mixer to do the switching. Sound should not go through a daemon.
Comment
-
Originally posted by darkphoenix22 View PostI have no problems with the ideals of PulseAudio. I just believe that per-app controls and audio mixing should be handled by the driver.
And the auto-routing should just use the plain ALSA mixer to do the switching. Sound should not go through a daemon.
Comment
-
Originally posted by mugginz View PostBut then you're advocating that the complexity of PulseAudio should go into the driver proper instead. That seems to be at odds with any goals of simplicity and low-latency at the driver level. You seem to be saying put Pulse directly into the driver.
Comment
-
Originally posted by darkphoenix22 View PostObviously the mixer has the ability to switch audio devices on its own given the drop-down menu. Why can't the autodetection be added to it simlar to a Volume Manager? This way the applications can talk directly to the ALSA drivers, while providing the automated audio switching.
Do you see I problem with this type of architecture? I certainly do.
Comment
-
Comment