Page 3 of 9 FirstFirst 12345 ... LastLast
Results 21 to 30 of 88

Thread: Ubuntu Desires Lower Audio Latency For Gaming

  1. #21
    Join Date
    Jun 2012
    Posts
    119

    Default

    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)

  2. #22
    Join Date
    Apr 2010
    Posts
    21

    Default

    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.
    Last edited by tkmorris; 11-01-2012 at 08:56 PM.

  3. #23
    Join Date
    Oct 2007
    Posts
    1,329

    Default

    Quote Originally Posted by Thaodan View Post
    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.

  4. #24
    Join Date
    Jun 2011
    Posts
    840

    Default

    Quote Originally Posted by ShadowBane View Post
    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. ).

    Quote Originally Posted by ShadowBane View Post
    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
    Last edited by ninez; 11-01-2012 at 09:46 PM.

  5. #25
    Join Date
    Nov 2012
    Posts
    151

    Default

    Quote Originally Posted by tkmorris View Post
    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...-in-linux.html
    http://insanecoding.blogspot.de/2009...-so-sorry.html


    best regards
    Nuc!eoN

  6. #26
    Join Date
    May 2010
    Posts
    187

    Default

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

  7. #27
    Join Date
    Dec 2011
    Posts
    38

    Default

    Hi, ubuntu developers!

    Welcome to the real world
    Last edited by unknown2; 11-01-2012 at 10:30 PM.

  8. #28
    Join Date
    Jul 2012
    Posts
    669

    Default

    Quote Originally Posted by ShadowBane View Post
    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....

  9. #29
    Join Date
    Jun 2012
    Posts
    119

    Default

    Quote Originally Posted by AJSB View Post
    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.

  10. #30
    Join Date
    Apr 2008
    Location
    NJ
    Posts
    82

    Default

    Quote Originally Posted by ShadowBane View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •