Ubuntu Desires Lower Audio Latency For Gaming

[ShadowBane]

There are several reasons to use PA instead of Jack as the primary sound server:

1: CPU/power usage. Jack uses a lot more CPU time than Pulse does.
2: Resampling. Pulse does it when necessary, Jack doesn't.
3: Per-Application volume control. Pulse can do stuff like this, jack can't easily (you can put in plugins, but they add latency and cpu overhead, also they would be a lot of work for end users)
4: Ease of configuration. Pulse pretty much sets itself up, jack takes a while to configure for low latency.
5: Ability to deal with jitter/high cpu usage. Jack gets buffer under-runs quite a bit as you push down the latency and boost the cpu usage, Pulse handles these situations much more gracefully.


As a side note, 25ms is still well within the acceptable latency range, I run around that on synths/guitar/other musical stuff and it doesn't feel laggy. 5ms is pretty much impossible on standard HDA stuff (you will get lots of buffer under-runs)

[tkmorris]

It should be interesting to add OSS4 to the tests since it does mixing in-kernel, possibly it will have the lowest latency of all the aforementioned alternatives.

I used it for teamspeak2 until I found out how to set the multiplexer cache and periods correctly, thus making aoss32 sound flawless (tested for quality side by side). The biggest downsides are drivers (functionality missing, my auto-mute stopped working), and sleep-wake support (not present at all), but stability/latency was never a problem for me.

[DanL]

Will Ubuntu try to improve it for all or only for itself like with any other thing they done.

The audio front is one area where Ubuntu regularly sends fixes and code upstream (both ALSA and pulse). The Ubuntu=leech meme just gets repeated by people who heard it somewhere, but have no clue.

[ninez]

There are several reasons to use PA instead of Jack as the primary sound server:

1: CPU/power usage. Jack uses a lot more CPU time than Pulse does.
2: Resampling. Pulse does it when necessary, Jack doesn't.
3: Per-Application volume control. Pulse can do stuff like this, jack can't easily (you can put in plugins, but they add latency and cpu overhead, also they would be a lot of work for end users)
4: Ease of configuration. Pulse pretty much sets itself up, jack takes a while to configure for low latency.
5: Ability to deal with jitter/high cpu usage. Jack gets buffer under-runs quite a bit as you push down the latency and boost the cpu usage, Pulse handles these situations much more gracefully.

I agree with most of what you say here, but;

about 5: daily on my system jackd is running 1-2ms @ 96khz (but can reduce frames - without xruns), i can flood my system with things to do, like compiling (-j4 ) or compiling the linux kernel, be watching HD video online or xbmc, while using soft-synths/VSTis, sooperlooper, ardour3 + 16-32channels of audio / midi + FX (or more) ~ no problem ZERO xruns, and in this scenario, 3 cores will be spiked at 99% while the other is using heavy amounts, as well. Claiming that PA handles these situations more gracefully is retarded (no offense - i'm not calling you retarded, just what you said in number 5..

It sounds to me like you must have you cpu governor settings setup like total crap, using 'ondemand' (improperly configured/tuned for jackd usage) if you get so many xruns on high cpu usage. (being as Jackd really wasn't designed with power-saving / frequency-scaling in mind - nor should it be. ).

As a side note, 25ms is still well within the acceptable latency range, I run around that on synths/guitar/other musical stuff and it doesn't feel laggy. 5ms is pretty much impossible on standard HDA stuff (you will get lots of buffer under-runs)

The human ear (on average) can detect just a few ms. 25ms is unacceptable for any real/classically trained piano/keyboard player. You are talking about significantly higher latencies than a real piano has, how you can claim you don't notice it is, laughably nutz.

also, it entirely depends on which HDA it is. Some are crappier than others. I have one in my old dell laptop that has an intelHDA that doesn't start dishing out xruns until i get it to 1ms, but it was quite comfortable around 2ms.

cheerz

[Nuc!eoN]

It should be interesting to add OSS4 to the tests since it does mixing in-kernel, possibly it will have the lowest latency of all the aforementioned alternatives.

I used it for teamspeak2 until I found out how to set the multiplexer cache and periods correctly, thus making aoss32 sound flawless (tested for quality side by side). The biggest downsides are drivers (functionality missing, my auto-mute stopped working), and sleep-wake support (not present at all), but stability/latency was never a problem for me.

I totally agree. In my Opinion OSSv4 is THE BEST soundsystem for Linux. The latency should be on par with jack.
A simple example from my own experience (and actually the reason why I switched to OSSv4):
When I tried to change the volume in the VLC-Player with default ALSA, I was SHOCKED that this simple action had a latency of 5 seconds!! I decided that is not bearable and I tried out OSSv4. Since that day I am in love with OSS. There is no noticable latency. Same for input, when I plugged in my Guitar. The OSSv4 mixer is very configurable (but attmitedly unstructured). Moreover I noticed, that the sound qualtity (music) was - in my opinion, considerably better with OSSv4 (but it was just one of the first impressions I got after installing OSSv4 and I never really tested this - but I shall)


What do we need more? For me thats enough. If truth be told, I've never once used PA - however I'm quite new to Linux
Now that OSS is OpenSource again, there is no reason not to support it.

Articles that I found very interesting concerning this topic:

http://insanecoding.blogspot.de/2007/05/sorry-state-of-sound-in-linux.html

http://insanecoding.blogspot.de/2009/06/state-of-sound-in-linux-not-so-sorry.html

best regards
Nuc!eoN

[Nevertime]

I thought the entire idea behind unity was to slow the desktop down until the sound got in sink :P

[unknown2]

Hi, ubuntu developers!

Welcome to the real world

[AJSB]

There are several reasons to use PA instead of Jack as the primary sound server:

1: CPU/power usage. Jack uses a lot more CPU time than Pulse does.
2: Resampling. Pulse does it when necessary, Jack doesn't.
3: Per-Application volume control. Pulse can do stuff like this, jack can't easily (you can put in plugins, but they add latency and cpu overhead, also they would be a lot of work for end users)
4: Ease of configuration. Pulse pretty much sets itself up, jack takes a while to configure for low latency.
5: Ability to deal with jitter/high cpu usage. Jack gets buffer under-runs quite a bit as you push down the latency and boost the cpu usage, Pulse handles these situations much more gracefully.


As a side note, 25ms is still well within the acceptable latency range, I run around that on synths/guitar/other musical stuff and it doesn't feel laggy. 5ms is pretty much impossible on standard HDA stuff (you will get lots of buffer under-runs)

Actually:

1. I don't consider that a benefit but a problem.

2. That's not exactly true....i run pura ALSA and i still can adjust per application volume...each game has i'ts one volume, VLC, IIRC same goes to Flash, etc.etc....do, no need for PA for that....

[ShadowBane]

2. That's not exactly true....i run pura ALSA and i still can adjust per application volume...each game has i'ts one volume, VLC, IIRC same goes to Flash, etc.etc....do, no need for PA for that....

This is 2012, almost 2013. The mixer being able to change the volumes of applications is useful and rather standard these days.

[gQuigs]

This is 2012, almost 2013. The mixer being able to change the volumes of applications is useful and rather standard these days.

That seems like the only benefit for the *average* user, but pretty much no *average* user is ever going to modify per-application volume in this way. A "hack" to allow the volume control applet to directly modify volumes exposed from applications would let us get this benefit, while keeping the stack just ALSA.