Hi,
Thought it might be useful to say that this did fix the issue.
It seems that on Ubuntu, if you install jack then these permissions get set for
you as part of the install. I imagine this is why a good number of people using
Ubuntu won't run into it. Unfortunately, without these permissions set, mixxx
will regularly under run. So perhaps it might be worth adding similar code to
the mixxx Ubuntu package, and/or a warning in mixxx itself?
Anyway, all running very smoothly now at 5ms. Thanks.
Cheers,
Sam
From: RJ Ryan [mailto:rr...@mixxx.org]
Sent: 14 February 2013 15:45
To: Sam Martin
Cc: mixxx-devel@lists.sourceforge.net
Subject: Re: [Mixxx-devel] Linux latency performance
Hi Sam,
We do set thread priorities but if your user account doesn't have the
permissions to set them via /etc/security/limits.conf then these priority
changes do nothing. Have you made this change?
http://www.gentoo.org/proj/en/desktop/sound/realtime.xml
See the bit about 'rtprio'.
Thanks,
RJ
On Thu, Feb 14, 2013 at 10:10 AM, Sam Martin
<sam.mar...@geomerics.com<mailto:sam.mar...@geomerics.com>> wrote:
Hi everyone,
I've been looking at things that force my Ubuntu linux install of Mixx to miss
buffer updates (audio glitches). I have a low latency kernel installed with the
usual low latency linux tweaks, and a uca202 audio interface, but see glitches
even when running with large buffer sizes.
I had some success by using htop (a basic linux performance monitor) to monitor
cpu intensive applications, and boosting the 'niceness' of non-mixx
applications. Making metacity, x11 and other graphics-related apps nicer helps,
but it turns out the biggest glitches actually come from mixx itself.
I haven't studied the code yet, but it appears to launch a fairly large number
of threads which compete equally for cpu time. I've found that if I make the
main mixx thread nicer (effectively decreasing it's scheduling priority and
making it more likely to be pre-emptied), and identify and do the same to the
threads that seem to do analysis work when you first load a track, the vast
majority of glitches go away. I'm guessing the kernel is then doing a better
job at pre-empting these threads, allowing the time critical ones to run
promptly.
So, is mixx doing anything to hint about which of its threads are high/low
priority? Could it be setting the niceness of each thread (at least on linux)
based on context somehow?
If this sounds sensible, and someone can give me a few pointers to get started,
I'd be happy to consider making a patch.
Cheers,
Sam
p.s. great work btw!
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net<mailto:Mixxx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
