search

mixxxdj / mixxx

Mixxx is Free DJ software that gives you everything you need to perform live mixes.
http://mixxx.org
Other
4.45k stars 1.27k forks source link

audio xruns on track load #5347

Closed mixxxbot closed 2 years ago

mixxxbot commented 2 years ago

Reported by: samotham Date: 2010-02-28T19:09:51Z Status: Fix Released Importance: High Launchpad Issue: lp529614 Tags: break, glitch, load, track, underrun Attachments: [Analyser Queue CPU Throttle](https://bugs.launchpad.net/bugs/529614/+attachment/1502375/+files/Analyser Queue CPU Throttle), [Log of xrun on ck-kernel, analysis of multiple files](https://bugs.launchpad.net/bugs/529614/+attachment/1511358/+files/Log of xrun on ck-kernel, analysis of multiple files), [iltony's mixxx 1.8 anti glitches patch attempt (11-10-2010)](https://bugs.launchpad.net/bugs/529614/+attachment/1686059/+files/iltony's mixxx 1.8 anti glitches patch attempt (11-10-2010)), [Test patch that may resolve xrun on track load issues.](https://bugs.launchpad.net/bugs/529614/+attachment/1687278/+files/Test patch that may resolve xrun on track load issues.)

how to reproduce the bug :

i'm on Karmic on 2.6.31-19-generic on a Vaio laptop Intel(R) Pentium(R) 4 CPU 2.80GHz graphic card radeon mobility 9200 audio card TerraTec Electronic GmbH Aureon 5.1 MkII desktop environment LXDE/Openbox

actually, there are glitches also on 1.7.2 version but much less (a small one when the waveform is being displayed i found).

mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-09-13T15:27:19Z

Hi all,

While I don't think this bug is gone for good, there have been some big performance improvements in the 1.8 branch over the past week so Mixxx should be less CPU hungry. I wouldn't be surprised if that has improved this problem a little bit for some of you.

Thanks, RJ

mixxxbot commented 2 years ago

Commented by: danielhjames Date: 2010-09-17T09:03:26Z

Hi Owen, see my comment #⁠48 - I can reproduce this bug with debugging turned off completely if I load a FLAC file, but WAV files are OK. Are you playing WAVs or FLACs?

FLACs seem to decode faster than lossy files, but maybe there's a sudden hit on the CPU instead of a longer, lower load. Is it possible to lower the priority of the FLAC decoding process, like Mixxx already does for the analyzer thread, so that it doesn't compete with the audio callback thread?

mixxxbot commented 2 years ago

Commented by: d00guan Date: 2010-09-18T16:22:33Z

"create #ifdefs for all qdebug statements inside the audio threads so that when mixxx can be built with or without those debug statements triggered. I think the default should be that debug=1 doesn't include those debug statements, but debug=2 enables them. That way developers can still have useful debug information, but DJs can still use mix without horrific xruns on every track load."

Isn't it better to have a runtime debug flag? That way it's easier to get debug output from users if needed. The extra if statements should not affect the performance much.

mixxxbot commented 2 years ago

Commented by: iltony Date: 2010-10-05T16:16:56Z

Can confirm. Audio glitches while loading new tracks are very audibile. Tried both alsa and jack, two different soundcards (a Phonic Helix Board Firewire 18CH and a Hercules DJ Console Mk2), latency set to 23ms (quite high), tried RJ patch as well... no luck at all! BTW mixxx 1.7.2 was quite fine, so the question is: what changed in the audio engine between the two versions? What I can see, is that now, when I load a track, cpu usage goes very very high (>100%), which in the past didn't appened. There's nothing wrong with it. But since we're in a real time context maybe if we can slow things down a bit (a sleep somewhere?)... But it's a really dirty approach... there should be something wrong about priorities.

mixxxbot commented 2 years ago

Commented by: jkittsmiller2 Date: 2010-10-06T14:12:55Z

I'm also having this issue but with compressed audio only (mp3, ogg, flac, etc.) wav files are not affected, this may have something to do with the codec's. I believe it is probably more of a codec loading / unloading issue on Linux other than anything else, either the way in which Linux is handling them or the way in which Mixxx is accessing them. What does everyone else think?

mixxxbot commented 2 years ago

Commented by: iltony Date: 2010-10-06T22:15:29Z

I believe James Kittsmiller has it right. I did some detailed test, and I discoverd that that same issue is reproducible not only while loading a new track (with all the stuff such as bmp detection, waveform rendering and so on), but also everytime seeking through a new position of a (compressed) audio file. Whenever seeking, to 0 (while loading) or to any position in the song, both audio streams stops for a frame or two before going on normally. The bug is more reproducibile while on a high cpu load, so for debugging porpouse it might a good idea to force such a situation and test it down. In order to verify this hypotesis about codecs, I tried to compile with ffmpeg support, but that didn't work because of compilation error. I also tried about forcing some memory unlock, but that didn't help either, so I'm propending towards codecs issue.

mixxxbot commented 2 years ago

Commented by: wolfgang-winter-gmx Date: 2010-10-11T09:06:02Z

I have the same "bug", audio xruns when loading a track at a windows System:

Without asio4all, with DirectSound, Sound running only very sloooooow. (not usable)

mixxxbot commented 2 years ago

Commented by: iltony Date: 2010-10-11T20:39:23Z Attachments: [iltony's mixxx 1.8 anti glitches patch attempt (11-10-2010)](https://bugs.launchpad.net/mixxx/+bug/529614/+attachment/1686059/+files/iltony's mixxx 1.8 anti glitches patch attempt (11-10-2010))

Oh yeah! Think I kinda got it. Here it is:

in file: mixxx/src/cachingreader.cpp
@line 514: freeAllChunks();

just comment the line, so that it looks like:

// freeAllChunks();

compile with scons and run again. Memory usage slowly rises while loading new pretty tracks, as expected, but, hey!, glitches are (mostly) gone. Looks like working. Obviously this ain't no production patch (and I'm not sure about it, I swam through the code and found this) but... does anybody want to give it try?

mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-10-12T00:56:08Z

Hey iltony and everyone,

Thanks for your patience with us while we figure this bug out. It's a really tricky one. I'm testing a fix right now. I'll have a patch posted later tonight.

thanks, RJ

mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-10-12T07:41:35Z Attachments: [Test patch that may resolve xrun on track load issues.](https://bugs.launchpad.net/mixxx/+bug/529614/+attachment/1687278/+files/Test patch that may resolve xrun on track load issues.)

Hi everyone,

Thanks to all your reports, I was able to track down what was causing this. There was a clear lock-up in the mixing engine which was triggered by loading a track while another was playing.

If you are able to compile from source, please undo your edits and try the attached patch. Post here whether or not the patch worked for you. If it turns out that this patch fixes the problems people are having, we will release a Mixxx 1.8.1 with this and some other bug fixes applied very soon to get the fix out to everyone affected by this bug.

Thanks for your patience, RJ Ryan

mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-10-12T07:44:57Z

To Wolfgang Winter,

If your sound is running too slowly in general with ASIO, you probably need to increase your latency.

RJ

mixxxbot commented 2 years ago

Commented by: Pegasus-RPG Date: 2010-10-12T11:12:20Z

Patch tests good for me on a slow Linux system.

mixxxbot commented 2 years ago

Commented by: iltony Date: 2010-10-12T18:29:22Z

Mixxx works better now with the latest RJ patch (works like it did with mine). Glitches on audio while loading new tracks happen less frequently. Glitches on user interface are still very notable, but that's something which does not affect the quality of a live stage... Feels like there are still things which can be tuned here and there (since mixxx 1.7.2 achieved lower latencies), but the improvement is notable.

mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-10-13T15:29:32Z

`teaser' on IRC also reports that this fixes the issue. Has anybody else tried it?

mixxxbot commented 2 years ago

Commented by: esbrandt Date: 2010-10-13T19:02:11Z

As iltony stated there are still some audio issues, but the patch solves this particular issue for me with MacOSX. Tested with reference sound from /mixxx/src/test/soundFileFormats/

mixxxbot commented 2 years ago

Commented by: d00guan Date: 2010-10-14T18:39:40Z

I updated to latest from 1.8 branch and can confirm s a real improvement. The issue might be completely solved. Lately I've noticed longer a freeze if I've had one deck playing and one empty, and then loaded a track to the empty deck. This is completely gone now. You're my hero of the day RJ Ryan!

I can also confirm a huge over all performance improvement from using jackd2 over the old jackd in Ubuntu.

mixxxbot commented 2 years ago

Commented by: asantoni Date: 2010-10-14T18:50:11Z

Anders: I'm going to point the next asshole that comes along and blames PortAudio for our performance problems and tells us to use the JACK API natively at your comment.

Thanks for the ammo!
On 2010-10-14 11:46 AM, "Anders Gunnarsson" <email address hidden>
wrote:
> I updated to latest from 1.8 branch and can confirm s a real
> improvement. The issue might be completely solved. Lately I've noticed
> longer a freeze if I've had one deck playing and one empty, and then
> loaded a track to the empty deck. This is completely gone now. You're my
> hero of the day RJ Ryan!
>
> I can also confirm a huge over all performance improvement from using
> jackd2 over the old jackd in Ubuntu.
>
> --
> audio xruns on track load
> https://bugs.launchpad.net/bugs/529614
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-10-14T19:21:35Z

Since I've has many reports of this issue being fixed, I'm going to mark this fixed. This fix will be released in Mixxx 1.8.1 which we will release, along with some other bugfixes, very shortly.

Thanks to everyone who helped solve this with your useful debugging and feedback. People may experience xrun's on track load still, but this is probably not an inherent bug, rather a problem with having too-low latency or something similar.

mixxxbot commented 2 years ago

Commented by: d00guan Date: 2010-10-14T19:32:57Z

Albert: Please do! I'm not sure I can explain why though. Guess some improvements have been made to jack. I was quite puzzled after upgrading to Ubuntu 10.10, when I was able to run Mixxx almost glitch free with jack, on the generic kernel with CPU-scaling set to on-demand and before applying this patch.

I will also try to run jack with default time-out from now on to see if RJs patch helps with the disconnection problem.

mixxxbot commented 2 years ago

Commented by: funkoolow Date: 2010-11-20T14:21:09Z

hi, i'm still experiencing the xruns on file load on ubuntu studio 10.10 and mixxx 1.8.1, running on eeepc900. Maybe it's an hardware capability problem, but i'm not sure since everything runs very smooth except for that damn file load. please let me know what to report to diagnose and thank you all for the patient support.

mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-11-20T15:02:12Z

Hi funkoolow,

Could you please let us know which sound API you are using and also whether the xruns happen at any latency or just low-latency? Also, what is your CPU speed?

Thanks, RJ Ryan

mixxxbot commented 2 years ago

Commented by: Pegasus-RPG Date: 2010-11-22T07:05:08Z

Also, are you using FLAC files? If so, you may be seeing bug #⁠666052.

mixxxbot commented 2 years ago

Commented by: iltony Date: 2011-02-01T18:14:52Z

I'm deeply investigating the issue. To all those are experimenting sound glitches while loading a new track, could you please run this:

while true; do     if on_ac_power; then         nice /usr/bin/nvidia-settings -q all > /dev/null; cpufreq-selector -g performance;     else cpufreq-selector -g ondemand;     fi;     sleep 25; done

in a shell, and let it go while using mixxx? Do you see any improvement? It looks to me like there might still be some issue not strictly mixxx-related, but more than that originated from video driver preempting everything. Please let me know if you notice further improvement (notice: this applies only to those one who use an Nvidia graphic adapter).

mixxxbot commented 2 years ago

Issue closed with status Fix Released.