I don't care where the code is. I only care if it doesn't allow apps and libraries to address ALSA like they expect. And if it reprocesses the audio and buffers the audio, causing extra latency.
Announcement
Collapse
No announcement yet.
Linux is not ready for Steam
Collapse
X
-
Sound APIs
Recap for my own sanity:
1) So with OSSv4, many functions that are not essential to run in kernel space are included there and it uses some bizarre method of interrupt handling that likely excludes it from kernel inclusion as well.
2) PulseAudio causes issues with QoS in some circumstances due to how it handles driver interaction and buffering.
3) We could use ALSA.
I suppose the point of this argument from the beginning has been that the sound APIs preclude Linux from being a viable platform for Steam to release on because it would be too difficult for Valve and its clients (game manufacturers) to manage all of the differences.
I think the real issue here is a surplus of choice and not many good ones.
Is there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?
Comment
-
Originally posted by darkphoenix22 View PostI don't where the code is. I only care if it doesn't allow apps and libraries to address ALSA like they expect. And if it reprocesses the audio and buffers the audio, causing extra latency.
If an ALSA driver has a bug you don't throw all of ALSA out, you fix the driver. If Pulse has a specific issue with a particular piece of middleware then you can patch either the middleware, Pulse or both.
Comment
-
Originally posted by p0larity View PostRecap for my own sanity:
1) So with OSSv4, many functions that are not essential to run in kernel space are included there and it uses some bizarre method of interrupt handling that likely excludes it from kernel inclusion as well.
2) PulseAudio causes issues with QoS in some circumstances due to how it handles driver interaction and buffering.
3) We could use ALSA.
I suppose the point of this argument from the beginning has been that the sound APIs preclude Linux from being a viable platform for Steam to release on because it would be too difficult for Valve and its clients (game manufacturers) to manage all of the differences.
I think the real issue here is a surplus of choice and not many good ones.
Is there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?
Comment
-
Originally posted by mugginz View PostBut if you're arguing for the complete elimination of a project due to a implementation specific failure then every project that's not perfect needs to be eliminated which doesn't leave us with much code.
If an ALSA driver has a bug you don't throw all of ALSA out, you fix the driver. If Pulse has a specific issue with a particular piece of middleware then you can patch either the middleware, Pulse or both.
Again the problem with PulseAudio isn't the ideals. It's implementation. It breaks things as it meddles where it doesn't need to meddle.
There no reason why PulseAudio needs to rebuffer and reprocess the audio. And furthermore, there's no reason why that process can't be bypassed.
Comment
-
-
Originally posted by darkphoenix22 View PostIt has issues with about 10 kinds of middleware.
Again the problem with PulseAudio isn't the ideals. It's implementation. It breaks things as it meddles where it doesn't need to meddle.
There no reason why PulseAudio needs to rebuffer and reprocess the audio. And furthermore, there's no reason why that process can't be bypassed.
Comment
-
Originally posted by mugginz View PostBut there is a need to do this. Especially when you're got no hardware mixing. If Pulse doesn't do it then ALSA must dmix it. Either way, something has to. I personally find Pulses audio mixing sounds better as well.
Comment
-
Originally posted by p0larity View PostIs there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?
Comment
Comment