Hey Owen,
I agree with Albert about taking a look at the gprof to see where Mixxx
spends the bulk of its time. If you want lower latency, the EQs are you
first stop. Sound dropouts -- xruns -- are completely different. They're
caused by random spikes in CPU usage, and not something like the EQs which
take a roughly constant amount of work to compute each time through the
audio callback thread. It's hard to pickout xruns from gprof output though,
like the skip on track load problem.
I spent a long time staring at profiler output in our 1.8 builds trying to
figure out why Mixxx was skipping on track load. If you are running an RT
kernel, then this might not apply to you. I have a 2.4ghz Core 2 Duo, and I
was getting skips on track load. When I changed my /etc/security/limits.conf
to include the following lines:
rryan - rtprio 99
rryan - nice -10
rryan - memlock unlimited
Mixxx 1.8.0 no longer skipped when I loaded tracks. This is because without
these lines, in userland on regular Linux, no process can make any of its
threads have differing priorities. That means that the Mixxx audio callback
thread (the one that, if it takes too long causes Mixxx to skip) has the
same priority as the track analyser thread. The track analyser basically
blows through the audio file you load as fast as it can, decoding the entire
thing and generating things like the waveform and measures the song BPM.
This means terrible things for the audio callback thread, because it's on
equal footing with a thread that is truly trashing both your CPU and the
disk. We tell Qt to set the analyser thread to the lowest possible priority,
but this is all for naught because with default settings in Linux, this does
nothing. I had this feeling that Mixxx always performed better on OSX and
Windows -- and it turns out that it was true because of this issue.
I would try addding those lines to your /etc/security/limits.conf just to
see if it helps your problem. I've heard that in Ubuntu Studio these
settings are enabled by default, though in 9.10 with an RT kernel this might
not be the case.
You can try it 'right now' by running as root -- but I wouldn't suggest that
as a permanent solution.
As for your findings that the audio dropouts occur more regularly with MP3
compared to other files -- this makes sense. You're right that our MP3
decoding code does tons of work when it is created. This is a limitation of
the libmad library. In Mixxx we require sample-accurate seeking. Not all
MP3s are capable of this. Basically, when we load a file, we have to scan
through the entire file and build a seek table that gives us more
information about what samples correspond to which frames in the MP3.
You didn't mention which version you were using, but I'm assuming its 1.7.2.
1.7.2 does not set the callback thread to higher priority, it just sets all
the other threads to lower priority. The 1.8.0 engine is faster than the
1.7.x engine -- I would be interested to hear how 1.8.0 beta 1 performs on
your system.
Please try that out and let the list know what the result is.
RJ
On Sun, Feb 7, 2010 at 11:32 PM, Owen Williams <[email protected]> wrote:
> Thanks for the pointers. I'll try to get gprof running and poke at it
> that way. I also didn't realize that Mixxx had already gone the route
> of multiple backends and decided it wasn't worth it. That's good to
> know.
>
> I had been thinking of looking at the portaudio/jack code because the
> problems went away when I used just ALSA. But since I only notice pops
> when I'm loading a new track, the other way of solving the problem would
> be to try to figure out what mixxx is doing when it's loading a track
> that causes the pops in the first place. Once the tracks are loaded and
> playing, I don't get any pops at all.
>
> I also discovered that the pops are only reliably triggered by MP3
> files. Ogg and FLAC files perform much better. OGG seems to be the
> best -- the tracks load instantly and never cause a hiccup. Flac is
> also better, but sometimes hiccups. MP3s, however, nearly always cause
> a hiccup while they are loading.
>
> So now I'm also looking at the mp3 sound source, which front-loads a lot
> of processing just creating the object (starting with loading the whole
> file into memory and the copying it all into libmad). Would it make
> more sense to improve that code instead?
>
> thanks,
> Owen
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
