Ubuntu Desires Lower Audio Latency For Gaming

[bwat47]

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.

We should go forward, not backwards. Yeah, lets ditch pulseaudio for alsa and some ridiculous hacks!

[RealNC]

you are talking about OSS. With ALSA multiple programs can access the sound card.

No, they cannot. You're confusing the dmix device with the hardware device.

[cbamber85]

You know sound is a considerable slower media than light. Your brain can't even tell apart single pictures if they are shown within 16ms, most people can't even at 40ms. If you have a really trained ear you'll be able to tell apart sounds with 10ms latency, but I doubt [b]you[/] are able to do so. Just remember 25ms is the latency of the sound from a piano standing 10m away from you. Can you really tell the latency between the pianist triggering the string and you hearing it?

This is an utterly incorrect analogy, the visual cortex and auditory cortex of the brain work completely differently. As for the brain being able to separate out individual sounds - it's very fast. If someone clicks their fingers next to your ear, you know it's right next to your ear; if someone does it 10m away, you know it's 10m away - how? Because your brain 'measures' the time difference between reflections of the same signal as they take different paths down the ear canal (after bouncing off the folds of the outer ear), that's why you full 'surround' hearing despite only having two ears.

If you're recording sound on a PC, and monitoring whilst playing (the usual setup), anything over 10ms becomes noticeable. Gaming can a have a slightly higher latency because your brain will tie together the visual information with auditory, and at 60Hz that's ~17ms before the sound is heard a single frame after it should have been.

[curaga]

Again, people like to pick on Lennart Poettering but at least he actively tries to DO SOMETHING to fix up the Linux desktop, rather than just yakking over and over.

Yay, flamebaiting! Name one thing he has fixed, instead of made worse.

[gamerk2]

Take a look on Windows:

Windows XP: hardware mixing
Windows 7: change to software mixing which cause serious latency problem http://www.youtube.com/watch?v=iujDVsg_2xY
Windows 8: http://msdn.microsoft.com/en-us/libr.../br259116.aspx they realize their mistake and go back to hardware mixing again

I wonder those PA developers will follow the stupid Microsoft again?

To be fair, it made sense to re-design the Directsound stack as of Vista; it WAS getting on in years. And other audio API's (OpenAL, etc) were still H/W accelerated, just not directsound.

Problem is, XAudio2 basically beat out OpenAL as the API of choice, so OpenAL is basically dead on Windows at this point.

[gamerk2]

This is an utterly incorrect analogy, the visual cortex and auditory cortex of the brain work completely differently. As for the brain being able to separate out individual sounds - it's very fast. If someone clicks their fingers next to your ear, you know it's right next to your ear; if someone does it 10m away, you know it's 10m away - how? Because your brain 'measures' the time difference between reflections of the same signal as they take different paths down the ear canal (after bouncing off the folds of the outer ear), that's why you full 'surround' hearing despite only having two ears.

If you're recording sound on a PC, and monitoring whilst playing (the usual setup), anything over 10ms becomes noticeable. Gaming can a have a slightly higher latency because your brain will tie together the visual information with auditory, and at 60Hz that's ~17ms before the sound is heard a single frame after it should have been.

I agree. Audio latency is much easier to distinguish then video latency. And audio *should* be kept, at worse, in sync with Video output, meaning a latency < 16.67ms. Although less then 10 or so would be desirable.

[psycho_driver]

Would it be possible to just bypass pulseaudio and talk directly to ALSA when playing games?

I'm sorry to any PA developers but it's a steaming pile of crap. Ubuntu would be much better off ditching it and working on auto configuration utilities for ALSA.

[psycho_driver]

That results in the game taking exclusive control of the card. Nothing else will be audible. Which is a disaster. Unless you talk to the dmix device. In that case, you're back to high latency.

I've never had my dmix setup induce audio stuttering into games/other highly cpu intensive apps like PA does every other time.

[ninez]

You know sound is a considerable slower media than light. Your brain can't even tell apart single pictures if they are shown within 16ms, most people can't even at 40ms. If you have a really trained ear you'll be able to tell apart sounds with 10ms latency, but I doubt [b]you[/] are able to do so. Just remember 25ms is the latency of the sound from a piano standing 10m away from you. Can you really tell the latency between the pianist triggering the string and you hearing it?

Bringing down latency to the technical minimum is just a waste of energy for the sake of some retards that use the latency numbers as a kind of benchmark.

First off, you are in no position to be claiming what i can or can't perceive (nor can you make that claim about anyone else). secondly, Ears detect latencies that your sight can't even come close to detecting and that is a fact... third, humans can detect less than 10ms when it comes to audio. Fourth, I can easily tell the difference in latency when i am standing 10m away from my piano vs. sitting in front of it playing. (though, a more practical example would be using a keyboard + speaker, followed by moving the speaker 10ms away and testing again... Just like i can tell the difference between standing right next to my guitar amp vs. being at the other side of the basement (less than 10m). bringing down the latency to a technical minimum isn't a waste of energy, nor is it some 'benchmark'.

if you can't tell the difference between being right in front of a sound source vs. being 10m away ~ then you clearly don't have very sensitive ears. (if fact, i would say you have a mild handycap). So rather than going on about this, maybe instead you should take two of the same wav file, double track them and offset the 2nd wave by 25ms and actually see if you can tell the difference - if you still can't under that circumstance - you have terrible hearing.

[ninez]

I've never had my dmix setup induce audio stuttering into games/other highly cpu intensive apps like PA does every other time.

Yeah, something that i find analogous (on my jackd/ffado system) to the stuttering of PA, would be when i need to route an alsa app (ie: cannot use jackd directly - things like adobe flash, VMware, darkplays 11.1.c.a, skype(? i don't use it), etc). I have a couple of choices that use snd-aloop (alsa loopback device / virtual device) that these alsa apps will use - then i can use either alsa_in/alsa_out (tools that come with jackd that expose the loopback device into jack, as clients) or i can use zita-ajbridge....

Well, in this scenario alsa_in/out would be PA, while zita-ajbridge would be ALSA.

zita-bridge - solid, fast with no stuttering.
alsa_in/alsa_out - 'can' be clunky/choppy in some scenarios (while in others being just 'okay'.) It also can be a bit lossy, unless i want to throw a little cpu at the problem.

So obviously, you can imagine which solution that i personally use - zita-ajbridge instead of alsa_in/out, hands down. (and thus, in the scenario of ALSA vs. PA - i would be using alsa... Although, there are cases where PA is really needed, as discussed many many times here and elsewhere - i just wish ALSA had of been adapted/modernized/improved rather than introducing yet another soundserver (but that's just kicking a dead horse and isn't really my problem anyway... + if those were my only two choices i would probably be using CoreAudio, instead.).

cheerz