-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buffer underflow when adding a track #8693
Comments
Commented by: rryan Mixxx doesn't get nearly as much testing as it ought to on rt kernels -- it's possible we have some kind of priority inversion problem that only shows up on rt. But this shouldn't happen in general (our audio processing thread runs at a higher priority than the rest of Mixxx's threads). Do you see the same problem on a non-rt kernel? Out of curiosity, what are your CPU specs? |
Commented by: ronso0 I only run this sys (Ubuntu studio) with rt kernel. On vanilla Ubuntu on the same machine I experienced very lame (aka unsatisfiying) performance so I don't see a reason to install standard kernel. Should I, would the results help? I'm running mixxx on a AMD A4-3300M @ 1900MHz, full lshw attached. |
Commented by: daschuer What kind of hard disk do you have? |
Commented by: ronso0
|
Commented by: ywwg Almost certainly the issue is the low latency setting. A lot happens during track loading and that's a common place to experience dropouts even if you don't get dropouts during playback. Try doubling it to 10ms and see if the problem goes away. |
Commented by: daschuer From the scheduler theory, a real-time thread should not be suspended by any other thread. Since this seams to be not the case, we may have still locking calls, or it is an CPU frequency scaling issue, or it is just some extra engine work wen loading a track. Your AMD A4-3300M has a frequency scaling 1900 - 2500 MHz. This issue become worth when we consider hyper-threading (not the case here) It could be interesting to lock the cpu clock on 1900 MHz and check how the issue behaves than. |
Commented by: rryan Daniel's right -- the Mixxx RT thread (assuming it's actually getting Our use of signals/slots in the engine means we're constantly locking
|
Commented by: ronso0 @daniel: I already locked cpu when setting up for audio. @owen: I set it to 20ms. So far it didn't happen, even when playing 3 decks (keylock/speed set off) and adding a track to the 4th. Until now mixxx felt very responsive without dropouts, I'll see how it will do from now. |
Commented by: ronso0 I set latency back to 10ms to maybe catch some log output.
Still can't reproduce it, though. Neither when loading the same file, nor when also playing a .m4a (even a shitty one) on the other deck. As next step I will build a more recent kernel with preempt patch, see if that makes a difference. |
Commented by: daschuer The file encoding issues are probably unrelated, but
is suspicious. This message is issued form the DAC timing validation code. If the DAC timing provided by your audio API is valid normally, this massage can happen if the Engine thread is suspended, before it enters the Mixxx audio callback. The "Warning [Engine]" itself makes the issue worse since this concurrents with all the other messages, this can take loooong since ther might be an other lock at writing the mixxx.log to hdd. This message will be displayed only once per Mixxx run so not that big issue here. Do you have more [Engine] entries? I think I will enable this message only in developer mode ... |
Commented by: daschuer I think we should move the logging output to a thread. |
Commented by: Be-ing I have noticed this occurring regularly when I first load a track to a deck. Have you? See https://bugs.launchpad.net/mixxx/+bug/1641360 |
Commented by: ronso0 Me? Anyway, my update: |
Commented by: ronso0 I recently set pitch-bending to Rubberband and audible underflow is happening on almost any track load. Since playing track is not pitched, I'm wondering why pitch-bending engine has such an effect. |
Commented by: daschuer Rubberband requires ages more CPU than Sounddouch. If keylock is enabled the pitch-bending-engine is enabled as well even if it is not pitched. This is required for a click free transition. |
Commented by: uklotzde The reason might not only be CPU utilization but also disk I/O. I experience buffer underflows while performing rsync operations on unrelated disks, CPU is not an issue here. |
Commented by: uklotzde This bug is related or even a duplicate: We should decide which one is the master for tracking these issues. |
Commented by: ronso0 I moved to Bionic and use 4.16.18-rt12 now. I could test with 3.18.7-rt1 if that's of any help. |
Commented by: rryan
Uwe, did you check that it was a buffer underflow (Mixxx callback exceeds its deadline) or is it just a CachingReader cache miss? CachingReader is supposed to be able to cache miss and emit silence so that it doesn't block the rest of the callback. No file I/O should be happening in the callback so I don't see how disk I/O could cause xruns? |
Commented by: uklotzde Buffer underflows in the engine with audible artefacts while the audio was playing continuously. CachingReader is not affected. The audio file is located on an (internal) disk that contains only audio files and is neither affected by the rsync activities and nor used by any other application than Mixxx. |
Commented by: ywwg I've noticed an uptick in underflows with keylock on, even on my new laptop (i7-8550U) at ~10ms. Not a ton, mind you, just one or two per set, but that's up from never. Rubberband has always used a lot of CPU but it surprises me that every time I upgrade my laptop it's the same deep red in the cpu meter. (Can't we lazily precache rubber-banded track data at the current BPM instead of trying to do it on the fly?) In the past I've been able to get by with 10ms and two tracks on keylock... I'm not sure if the move to qt5 has caused a perf regression in general that has pushed me over the edge. |
Commented by: daschuer Since we recently fighting some possible qt5 performance regression, it would be nice if you could verify it. Is there a difference between qt5 and qt4? Is this issue qt related? You can either use the plain 2.1 branch or the 2.2 branch build with qt4 and this #1860 |
Commented by: uklotzde Caching of pre-computed audio data? Just NO! The caching is already complicated and error prone. This would introduce a whole new level of complexity. |
Reported by: ronso0
Date: 2016-11-16T01:27:09Z
Status: Confirmed
Importance: High
Launchpad Issue: lp1642105
Tags: engine
Attachments: lshw
Imagine one deck is playing, then you load a track to another deck.
That's where an audible buffer underflow happens.
Must admit, I set a pretty aggressive latency of 5.33ms but don't run into any underflows when playing two decks. Keylock/speed offset and massive effects don't have any impact on playback quality.
Loading a track shouldn't have such an apparently high priority because I suspect noone minds that 100ms more it takes to load and even to re-analyze a track.
mixxx rev5973
Linux 3.14.23-rt20 #1 SMP PREEMPT RT x86_64
The text was updated successfully, but these errors were encountered: