mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-02-28T21:11:53Z
Hey samotham,
When you say glitch, do you mean audio glitch or graphical glitch?
Thanks, RJ
Closed mixxxbot closed 2 years ago
mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-02-28T21:11:53Z
Hey samotham,
When you say glitch, do you mean audio glitch or graphical glitch?
Thanks, RJ
mixxxbot
commented
2 years ago mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-03-01T05:29:19Z
This is a known issue though I don't think we have a bug for it. I have a lot of work done in the lp:mixxx/features_sqlite branch which drastically improve this. These fixes will be incorporated into Mixxx 1.8.0 beta2 so please give that a try when it comes out. For now, you can increase your latency to eliminate audio xruns on track load.
Thanks very much for the bug report, RJ Ryan
mixxxbot
commented
2 years ago Commented by: samotham Date: 2010-03-01T23:21:06Z
ok good
then to be more precise, for info these xruns are not considered as real xruns by jack
mixxxbot
commented
2 years ago Commented by: samotham Date: 2010-03-07T23:17:50Z
for information as it might help back to 1.7.2, I still get some minor kind of xruns when loading a new track. Precisely, it appears just before the BPM is being displayed and waveform becoming fluid.
In the meantime, this week-end I checked on Windows XP, I don't get any xruns or glitch (using ASIO4all drivers on the same soundcard).
BTW shall I open a new bug report about this ?
mixxxbot
commented
2 years ago Commented by: sentenzux Date: 2010-04-06T15:50:48Z
Hi guys,
I'm getting the same behavior with karmic on a desktop system with a Q6600, so I guess performance should not be a problem... Setup is based on a edirol FA101 (firewire) and an external mixer, vinyl control is not used. Ardour is used for recording the mixer output via an input of the FA101.
If I first load my tracks a first time, reloading do not produce the same effect. Jack timeout is set to 2 sec (because otherwise mixxx crashes), and I do get around 1-2 sec of blank in my live output when I get this problem, however my recording by ardour only has a really small glitch and 1 xrun displayed.
mixxxbot
commented
2 years ago Commented by: asantoni Date: 2010-05-29T03:25:58Z
This situation should be significantly improved in trunk. Features_sqlite has been merged into trunk for some time (which brings in a slew of library performance enhancements), and we also now use memory mapped I/O for MP3 playback, which should also speed things up.
mixxxbot
commented
2 years ago Commented by: roland-robelix Date: 2010-06-06T12:20:07Z
Is this already in trunk?
I get audio glitches almost always when loading a song with rev 2421. Running on Gentoo, kernel 2.6.32-gentoo-r7, plain ALSA, no jack, no pulseaudio. T43, 2G RAM, 2GHz Pentium M, Mobility Radeon X300, NI A2DJ
1.7.2 runs fine with 21ms latency, 1.8 produces glitches even with 170ms.
mixxxbot
commented
2 years ago Commented by: asantoni Date: 2010-06-08T17:23:15Z
Yeah, this is in trunk. I recently made changes to SoundSourceMP3 which could have possibly done some bad things, but I got Owen to review them to make sure they were OK so I don't think I've done anything super dumb there (though it's still very possible).
Do you get xruns when you load OGG or FLAC files?
RJ, you were able to get xruns on load before you added the caching stuff, right? Can you test on your rig and see we've regressed on this recently?
Thanks, Albert
On Sun, Jun 6, 2010 at 5:20 AM, Robelix
Is this already in trunk?
I get audio glitches almost always when loading a song with rev 2421. Running on Gentoo, kernel 2.6.32-gentoo-r7, plain ALSA, no jack, no pulseaudio. T43, 2G RAM, 2GHz Pentium M, Mobility Radeon X300, NI A2DJ
1.7.2 runs fine with 21ms latency, 1.8 produces glitches even with 170ms.
-- audio xruns on track load (1.8.0beta1) 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: roland-robelix Date: 2010-06-12T19:33:28Z
It happens when loading mp3 or ogg, not with flac. The type of the playing file has no influence.
mixxxbot
commented
2 years ago Commented by: bkgood Date: 2010-07-08T19:07:18Z
Robelix, have you tried lowering your latency? I'm toying with a bug similar to this one (may be the same one), and I only seem to get these glitches on track load if my latency is >=10 ms.
Could you try 1 or 5 ms to see if the glitches still occur?
mixxxbot
commented
2 years ago Commented by: Pegasus-RPG Date: 2010-07-15T10:38:01Z
I still see this on my slowww Celeron D 2.53GHz. It is worse at higher latencies, but still detectable at 10ms.
mixxxbot
commented
2 years ago Commented by: d00guan Date: 2010-07-15T21:58:20Z
I've done some testing now, since I find it to be the most annoying thing with Mixxx right now. Otherwise 1.8 it looks promising!
I see it on all file types, though much more frequently for mp3 than for ogg, flac or wav. Then my q6 ogg files are around half the size of my mp3's which are mainly 320kbit. My system is a 1.8GHz Core2Duo (7100), X3100 laptop with 4gig ram running ubuntustudio 10.04 64bit. Reducing latency from around 10ms to 5ms gives more xruns. Mixxx version is trunk r2432.
mixxxbot
commented
2 years ago Commented by: bkgood Date: 2010-07-20T20:37:20Z
Ok I ought to throw my two cents in here because this seems like it should block 1.8 as it really makes Mixxx unusable for serious mixing (loading a new song kills your master out, if only for half a second).
I may be totally wrong here, but this seems to happen because ReadAheadManager (or CachingReader) insists on reading a handful (8 or so I think) of chunks from the file before it starts feeding to EngineBuffer, and it seems to block the rest of the audio callback thread until these 8 chunks are read. The ideal behavior would be to either just read what it needs and then fill in the rest as possible with another thread, but that appears to be what's happening now (or that's how I'm reading the code), so maybe the ideal behavior is to just keep returning buffers of zeros until the 8-or-whatever chunks have been acquired and playback can begin.
I haven't found where this blocks but that's about all I can figure is happening.
FWIW I first noticed this bug testing different FLAC files with my flac sound source, I noticed it starts skipping when the file is encoded at -3 or better (-3 and higher corresponds to a 4092 frame block size, so it's likely more difficult to decode), this bothered me for a while before I realized there was no way I could really make my code noticeably faster so I tested the same set of files with SSsndfile and found the same skips (at the same encoder levels) happen there too. This happens to me occasionally when playing other file types too (mp3 and m4a specifically); I think it's reasonable that Mixxx would skip if a soundsource couldn't decode one chunk of data in a callback period, but asking it to decode 8 or 10 of them in that short of time is quite a lot.Commented by: roland-robelix Date: 2010-07-20T21:47:24Z
Just tried the beta2 - and I also tried with latency set to 1,2 and 5ms
Since I get the "normal too low latency noises" all the time it's hard to say if there are additional glitches while loading a song.
mixxxbot
commented
2 years ago Commented by: roland-robelix Date: 2010-07-31T20:07:59Z
Think I've got that beast ;)I built the latest portaudio snapshot (2010-07-30) - and it runs just fine.
mixxxbot
commented
2 years ago Commented by: bkgood Date: 2010-08-01T16:48:21Z
On Saturday 31 July 2010 15:07:59 Robelix wrote:
Think I've got that beast ;)
I built the latest portaudio snapshot (2010-07-30) - and it runs just fine.
PortAudio has gone some optimization lately, so glad to know it fixed it for you. :) However, this definitely doesn't resolve whatever's going on in the mixxx codebase that was causing this to begin with (i.e. loading a song seems capable of blocking the audio callback thread).
Bill
mixxxbot
commented
2 years ago Commented by: d00guan Date: 2010-08-09T07:12:43Z
What Bill states sounds like a likely cause for the behaviour while loading tracks. Something seem to block for an instance. I bet this is the same cause that make jackd kick Mixxx if one don't use ridiculous values for timeout.
Is there someone with insight in this code that can confirm or deny what Bill states? For me this is a blocker, since I don't want these kind of breakups when playing live.
mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-08-09T18:40:53Z
Hi Anders, Bill, all,
There isn't really any code in the engine that will block based on an action taken in the UI. I could be wrong, but I think this problem is mostly just a combination of too-low latency setting and the various debug statements we have that print to the console on track load.
I just did an experiment where I turned off the EQs and the waveform summary, set one track playing, and then spam-loaded every track in my library to the second player. This ensures that the analyzer thread spends 100% of its time processing tracks (load from disk, calculate waveform, calculate BPM, etc).
The result was that audio xruns still occured at 5ms latency.
I took one more step and converted the ControlObject sync step to happen outside of the audio callback thread. The result was the same, xruns still occured on track load when I spam-loaded tracks to the player.
I then piped the output of Mixxx to /dev/null and retried. The result was the xruns occurred much less than before, very rarely. I even rate limited my CPU from 2.4GHz to 800MHz and xruns very very rarely occured.
I've reviewed the engine code again and there really isn't anything that will obviously block. It's possible theres something in there, but it's hiding very well.
I think that moving ControlObject::sync() out of SoundManager and into an EngineWorker is a good move overall, because nasty people (e.g. MIDI Script) could connect valueChanged or valueChangedFromEngine signals from a sync() to do some long running work or something that could block the engine thread, so a sync() call should not be in the engine callback.
RJ
On Mon, Aug 9, 2010 at 3:12 AM, Anders Gunnarsson <
wrote:
What Bill states sounds like a likely cause for the behaviour while loading tracks. Something seem to block for an instance. I bet this is the same cause that make jackd kick Mixxx if one don't use ridiculous values for timeout.
Is there someone with insight in this code that can confirm or deny what Bill states? For me this is a blocker, since I don't want these kind of breakups when playing live.
-- audio xruns on track load (1.8.0beta1) https://bugs.launchpad.net/bugs/529614 You received this bug notification because you are a bug assignee.
mixxxbot
commented
2 years ago Commented by: d00guan Date: 2010-08-19T22:25:18Z
Bummer.
The thing regarding debug messages sounds interesting though. Would it be easy to disable log of these messages by moving them to a log level other than default?
I get xruns even with Performance mode 1,8GHz on both my cores on a Core2Duo with ~10ms latency, and Mixxx as the only load on the system. Although I use jack on a realtime kernel, and have not been to pedant with what runs on my system, I think that it should be possible to get it free of xruns on track load.
If this was fixed Mixxx would really be a professional grade DJ software. Probably the best performing I know of.
mixxxbot
commented
2 years ago Commented by: pwhelan Date: 2010-08-19T22:46:29Z
Have you tried disabling the BPM detection and also getting output to pipe to /dev/null?
I'm thinking that if it's caused by the BPM detection code we could limit it's CPU usage dynamically. We just incur a small sleep if a process call to the analyzer uses too much CPU.
mixxxbot
commented
2 years ago Commented by: pwhelan Date: 2010-08-20T04:04:01Z Attachments: [Analyser Queue CPU Throttle](https://bugs.launchpad.net/mixxx/+bug/529614/+attachment/1502375/+files/Analyser Queue CPU Throttle)
Here is a patch for the 1.8 release that should throttle the CPU for the Analyzer Queue. If someone who is experiencing the XRUN problem could try it out and tell me if it fixes the problem it would be very helpful.
The patch has a few quirks but should be stable. Ocassionally it will over throttle. If this does fix the problem I'll go ahead with the cosmetics and such to get this into the final 1.8 release.
mixxxbot
commented
2 years ago Commented by: danielhjames Date: 2010-08-20T14:12:12Z
I noticed something similar using 1.8.0-beta2 when loading FLAC or WAV files in ALSA mode on 64 Studio 3.3 alpha (Karmic based with an RT kernel). To reproduce, get a track rolling in one player, then drag and drop another track from the library into the other player. There is a very short audio glitch in the playing track, but it's noticeable.
At first I thought this was due to the high default latency setting of 64ms - I dropped it to 10ms and the problem stopped temporarily. But when I restarted Mixxx, still set to 10ms, the problem came back.
BPM detection could be the cause, because I'm testing with a freshly imported library of audio files. Can I enable batch BPM detection, waveform generation etc. at library import time, rather than when I load the track into the player for the first time? OK, import would take longer, but then I'm not likely to be doing a mass file import in the middle of a live set.
I am running Mixxx on this HP ze2000 laptop as the sole application (no gdm, mixxx started from an .xinitrc file) so there is no desktop or window manager to interfere. The soundcard is a basic internal AC97 one at the moment. If I can't track down the cause, I will try Philip's patch above, and let you know if that fixes it.
Cheers!
Daniel
mixxxbot
commented
2 years ago Commented by: asantoni Date: 2010-08-20T17:11:38Z
Here's my 2 cents:
1) We can't sleep-limit the Analyser thread, just on principle. If you have a 10 GHz processor, we're not going to arbitrarily slow down any of our background threads on you. It's like the opposite of old DOS games running too fast on modern PCs, but it's the same type of thinking. There's a reason your OS has a scheduler.
2) The only people that are complaining here are Linux users.
3) Do you guys have the same xruns if they disable the waveform views? (Change the view to "Simple" or "Off" or whatever we call it now in the preferences.)
4) You can do batch BPM analysis via the "Analyze" tab in 1.8. We don't currently do waveform generation in advance because we're not entirely sure we want to save that to disk. (eg. if the waveform pixmap is 100 kb, then we'd need 1 GB of your disk space to cache the waveform for every song in your 10,000 song library.)
5) Your OS has a scheduler, let it work. If you have an RT thread, I'm very surprised that you could preempt it via some GUI action. The call graph that takes place when a song is loaded into a player is fairly complicated, and it would definitely help to have a diagram of this. If I have time to review the code again, I'll try to draw one.
Thanks, Albert
On Fri, Aug 20, 2010 at 7:12 AM, Daniel James daniel@64studio.com wrote:
I noticed something similar using 1.8.0-beta2 when loading FLAC or WAV files in ALSA mode on 64 Studio 3.3 alpha (Karmic based with an RT kernel). To reproduce, get a track rolling in one player, then drag and drop another track from the library into the other player. There is a very short audio glitch in the playing track, but it's noticeable.
At first I thought this was due to the high default latency setting of 64ms - I dropped it to 10ms and the problem stopped temporarily. But when I restarted Mixxx, still set to 10ms, the problem came back.
BPM detection could be the cause, because I'm testing with a freshly imported library of audio files. Can I enable batch BPM detection, waveform generation etc. at library import time, rather than when I load the track into the player for the first time? OK, import would take longer, but then I'm not likely to be doing a mass file import in the middle of a live set.
I am running Mixxx on this HP ze2000 laptop as the sole application (no gdm, mixxx started from an .xinitrc file) so there is no desktop or window manager to interfere. The soundcard is a basic internal AC97 one at the moment. If I can't track down the cause, I will try Philip's patch above, and let you know if that fixes it.
Cheers!
Daniel
-- audio xruns on track load (1.8.0beta1) 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: pwhelan Date: 2010-08-22T09:18:27Z
Here's my answer
1) The OS Scheduler under linux is highly uncooperative. Getting it to work requires at the very least chaning /etc/security/limits.conf. Should we see if our package maintaners would be ok with rolling out a /etc/security/limits.conf or limit.d file? This might be the best alternative. Hopefully it is sufficient.
2) I'm a linux user (grin)
3) I'd like to hear the answer to this one from some of the users having this problem.
4) I know, batch analysis is awesome and hopefully it'll get awesomer.
5) I currently have no problems with my OS scheduler since I'm running the CK kernel (from the ppa) and I added permissions to nice to -5 and change the rtprio to 90 to the audio group in my /etc/security/limits.conf file.
mixxxbot
commented
2 years ago Commented by: asantoni Date: 2010-08-22T17:51:17Z
Good points, Phil. We should find out if these users have tweaked limits.conf files or not.
Daniel: Does 64 Studio ship with a limits.conf file that allows applications to control the priorities of their own threads? eg. @audio - rtprio 90
We've found experimentally that by default, the Linux kernel does not allow applications to lower the priority of their own threads. This is terrible for Mixxx because it means our realtime audio thread might actually be running with the same priority as our background worker threads, and we've found that that can be a significant source of xruns and performance degradation. Tweaking limits.conf allows Mixxx to lower the priority of it's own threads, and provides a crucial performance boost that might even put Linux on par with Vista+ and OS X.
If anyone else hasn't tried tweaking this file, please follow the instructions under "Real-Time Support" here: https://help.ubuntu.com/community/UbuntuStudioPreparation (Remember to add your user to the "audio" group too!)
Thanks, Albert
On Sun, Aug 22, 2010 at 2:18 AM, Phillip Whelan
<email address hidden> wrote:
> Here's my answer
>
> 1) The OS Scheduler under linux is highly uncooperative. Getting it to
> work requires at the very least chaning /etc/security/limits.conf.
> Should we see if our package maintaners would be ok with rolling out a
> /etc/security/limits.conf or limit.d file? This might be the best
> alternative. Hopefully it is sufficient.
>
> 2) I'm a linux user (grin)
>
> 3) I'd like to hear the answer to this one from some of the users having
> this problem.
>
> 4) I know, batch analysis is awesome and hopefully it'll get awesomer.
>
> 5) I currently have no problems with my OS scheduler since I'm running
> the CK kernel (from the ppa) and I added permissions to nice to -5 and
> change the rtprio to 90 to the audio group in my
> /etc/security/limits.conf file.
>
> --
> audio xruns on track load (1.8.0beta1)
> 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.
>Commented by: rryan Date: 2010-08-22T18:42:48Z
Also, on Ubuntu proper, you need to either add yourself to the audio group, or make the limits.conf adjustments be for your username and not @audio. This is because on Ubuntu Desktop, pulse is the only member of the audio group.
mixxxbot
commented
2 years ago Commented by: d00guan Date: 2010-08-22T18:52:52Z Attachments: [Log of xrun on ck-kernel, analysis of multiple files](https://bugs.launchpad.net/mixxx/+bug/529614/+attachment/1511358/+files/Log of xrun on ck-kernel, analysis of multiple files)
I've made some more testing. My setup is a C2D running UbuntuStudio 10.04 with rt-kernel and Jack.
Jack is started with: jackd -R -t5000 -dalsa -dhw:1 -r44100 -p256 -n2
UbuntuStudio adds following to /etc/security/limits.d/audio.conf when jackd is installed: @audio - rtprio 99 @audio - memlock unlimited
I also tried to uncomment the last row, but don't think it changed performance.
With this setup I get xruns almost on every track load. Even though I have both kernels in Performance mode. If I disable waveforms I still get xruns but they occur less frequently.
After this I tested ck preemptive kernel with much better result. Thanks for the tip Phil! I can still get xruns to occur if I spam load tracks though, and may get an xrun on normal track load, but not to often. I attached a log of an xrun and of what happens during spam load described below.
While spam loading tracks I noted that tracks queued for analysis aren't removed even if a new track is loaded. The result is that every track is processed in sequence until the currently loaded track is processed. I know it isn't a normal use case, but it leads to an unnecessary delay until waveform is showed if a user load wrong track before loading the correct one.
mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-08-22T19:15:56Z
Hi Anders,
Thanks for the data. Did you pipe the output of Mixxx to a file while running it or was it outputting to stdout?
RJ
On Sun, Aug 22, 2010 at 2:52 PM, Anders Gunnarsson <
<email address hidden>> wrote:I've made some more testing. My setup is a C2D running UbuntuStudio 10.04 with rt-kernel and Jack.
Jack is started with: jackd -R -t5000 -dalsa -dhw:1 -r44100 -p256 -n2
UbuntuStudio adds following to /etc/security/limits.d/audio.conf when jackd is installed: @audio - rtprio 99 @audio - memlock unlimited
@audio - nice -19
I also tried to uncomment the last row, but don't think it changed performance.
With this setup I get xruns almost on every track load. Even though I have both kernels in Performance mode. If I disable waveforms I still get xruns but they occur less frequently.
After this I tested ck preemptive kernel with much better result. Thanks for the tip Phil! I can still get xruns to occur if I spam load tracks though, and may get an xrun on normal track load, but not to often. I attached a log of an xrun and of what happens during spam load described below.
While spam loading tracks I noted that tracks queued for analysis aren't removed even if a new track is loaded. The result is that every track is processed in sequence until the currently loaded track is processed. I know it isn't a normal use case, but it leads to an unnecessary delay until waveform is showed if a user load wrong track before loading the correct one.
** Attachment added: "Log of xrun on ck-kernel, analysis of multiple files"
https://bugs.launchpad.net/mixxx/+bug/529614/+attachment/1511358/+files/mixxx_ck-kernel.log
-- audio xruns on track load (1.8.0beta1) https://bugs.launchpad.net/bugs/529614 You received this bug notification because you are a bug assignee.
mixxxbot
commented
2 years ago Commented by: roland-robelix Date: 2010-08-22T19:17:46Z
I did a few tests with the beta2 on Gentoo x86 and the older portaudio from portage:
Switched off the Waveforms: no change.
Switched off BPM detection: no change.
Rea-time: Tried with the settings from the Ubuntu-page mentioned above and from http://www.gentoo.org/proj/en/desktop/sound/realtime.xml - no change. (BTW: How do I check if RT is really working?)
Reniced mixxx to -15: no change.
Diffrent latency settings change how the glitches sound but not the fact that there are some.
mixxxbot
commented
2 years ago Commented by: d00guan Date: 2010-08-22T19:29:52Z
Hi RJ,
It's console output, so I guess stdout. I skipped the initial library scan and init log.
mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-08-22T19:38:03Z
Hey Robelix,
Interesting, earlier on you said that updating to portaudio trunk helped. Is that still the case?
RJ
mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-08-22T20:25:05Z
Just got done messing around a little bit.
I have a Core 2 Duo 2.5GHz laptop (Lenovo T400) with 2gb of RAM. I wrote a patch that completely turns off any debug prints that happen as a result of loading a track. As a result, while running tons of other apps on plain old Ubuntu Desktop 10.04 with the limits.conf settings correctly set and SpeedStep ENABLED locking my CPU to 800MHz Mixxx running at 5ms latency through ALSA has 0 xruns. Not a single one. I spam-load my entire library and can't get it to xrun while a track is playing. (the spam-load pins the CPU at 100%, but still no xruns) I also tried using JACK connected through ALSA and still couldn't get an xrun. If I turn off this patch so Mixxx does debug output on track load again, I get xruns all over the place.
So, robelix, Anders, can you try piping the output to /dev/null and see what happens? The patch I applied is here if you are able to compile Mixxx 1.8 from source. http://pastebin.com/cd0vGzR5
mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-08-22T20:26:32Z
Oh, I'm using the latest version of portaudio-trunk, which has some performance improvements, but I'm definitely able to get xruns with portaudio trunk if I enable all those print statements.
mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-08-22T20:29:57Z
Actually, I just checked. Piping output to /dev/null still gives me xruns. If I run without those printlines enabled, no xruns. If you guys are able to compile from source, please apply my patch and test.
mixxxbot
commented
2 years ago Commented by: roland-robelix Date: 2010-08-22T22:25:28Z
Ryan, qith svn-portaudio it's far better but not perfect - xruns happen only once in about 100 songs. For testing I installed an older version of portaudio.
And I wanted to try your patch - but I'm not able to appy it (tried with beta2):
patching file src/analyserbpm.cpp Hunk #1 FAILED at 44. Hunk #2 FAILED at 72. 2 out of 2 hunks FAILED -- saving rejects to file src/analyserbpm.cpp.rej patching file src/analyserwaveform.cpp Hunk #1 FAILED at 53. Hunk #2 FAILED at 108. 2 out of 2 hunks FAILED -- saving rejects to file src/analyserwaveform.cpp.rej patching file src/analyserwavesummary.cpp Hunk #1 FAILED at 77. 1 out of 1 hunk FAILED -- saving rejects to file src/analyserwavesummary.cpp.rej patching file src/library/dao/cuedao.cpp Hunk #1 FAILED at 228. Hunk #2 FAILED at 244. 2 out of 2 hunks FAILED -- saving rejects to file src/library/dao/cuedao.cpp.rej patching file src/library/dao/trackdao.cpp Hunk #1 FAILED at 101. Hunk #2 FAILED at 316. Hunk #3 FAILED at 343. Hunk #4 FAILED at 489. Hunk #5 FAILED at 556. Hunk #6 FAILED at 719. 6 out of 6 hunks FAILED -- saving rejects to file src/library/dao/trackdao.cpp.rej patching file src/soundsourcemp3.cpp Hunk #1 FAILED at 26. Hunk #2 FAILED at 37. Hunk #3 FAILED at 139. Hunk #4 FAILED at 147. Hunk #5 FAILED at 524. Hunk #6 FAILED at 600. Hunk #7 FAILED at 626. Hunk #8 FAILED at 638. Hunk #9 FAILED at 688. Hunk #10 FAILED at 715. 10 out of 10 hunks FAILED -- saving rejects to file src/soundsourcemp3.cpp.rej patching file src/trackinfoobject.cpp Hunk #1 FAILED at 273. 1 out of 1 hunk FAILED -- saving rejects to file src/trackinfoobject.cpp.rej patching file src/waveform/waveformrenderer.cpp patch unexpectedly ends in middle of line Hunk #1 FAILED at 496. 1 out of 1 hunk FAILED -- saving rejects to file src/waveform/waveformrenderer.cpp.rej
mixxxbot
commented
2 years ago Commented by: rryan Date: 2010-08-22T22:38:15Z
You may need to check out the latest version from Bazaar. If you have bzr installed, just do:
`bzr checkout lp:mixxx/1.8'
And that should get you a checkout of the latest 1.8 code. If you can already build the beta2 code, that should work fine. The patch should apply cleanly against that.
On Sun, Aug 22, 2010 at 6:25 PM, Robelix
Ryan, qith svn-portaudio it's far better but not perfect - xruns happen only once in about 100 songs. For testing I installed an older version of portaudio.
And I wanted to try your patch - but I'm not able to appy it (tried with beta2):
patching file src/analyserbpm.cpp Hunk #1 FAILED at 44. Hunk #2 FAILED at 72. 2 out of 2 hunks FAILED -- saving rejects to file src/analyserbpm.cpp.rej patching file src/analyserwaveform.cpp Hunk #1 FAILED at 53. Hunk #2 FAILED at 108. 2 out of 2 hunks FAILED -- saving rejects to file src/analyserwaveform.cpp.rej patching file src/analyserwavesummary.cpp Hunk #1 FAILED at 77. 1 out of 1 hunk FAILED -- saving rejects to file src/analyserwavesummary.cpp.rej patching file src/library/dao/cuedao.cpp Hunk #1 FAILED at 228. Hunk #2 FAILED at 244. 2 out of 2 hunks FAILED -- saving rejects to file src/library/dao/cuedao.cpp.rej patching file src/library/dao/trackdao.cpp Hunk #1 FAILED at 101. Hunk #2 FAILED at 316. Hunk #3 FAILED at 343. Hunk #4 FAILED at 489. Hunk #5 FAILED at 556. Hunk #6 FAILED at 719. 6 out of 6 hunks FAILED -- saving rejects to file src/library/dao/trackdao.cpp.rej patching file src/soundsourcemp3.cpp Hunk #1 FAILED at 26. Hunk #2 FAILED at 37. Hunk #3 FAILED at 139. Hunk #4 FAILED at 147. Hunk #5 FAILED at 524. Hunk #6 FAILED at 600. Hunk #7 FAILED at 626. Hunk #8 FAILED at 638. Hunk #9 FAILED at 688. Hunk #10 FAILED at 715. 10 out of 10 hunks FAILED -- saving rejects to file src/soundsourcemp3.cpp.rej patching file src/trackinfoobject.cpp Hunk #1 FAILED at 273. 1 out of 1 hunk FAILED -- saving rejects to file src/trackinfoobject.cpp.rej patching file src/waveform/waveformrenderer.cpp patch unexpectedly ends in middle of line Hunk #1 FAILED at 496. 1 out of 1 hunk FAILED -- saving rejects to file src/waveform/waveformrenderer.cpp.rej
-- audio xruns on track load (1.8.0beta1) https://bugs.launchpad.net/bugs/529614 You received this bug notification because you are a bug assignee.
mixxxbot
commented
2 years ago Commented by: roland-robelix Date: 2010-08-22T22:52:09Z
same result with bzr version, the patch fails.
mixxxbot
commented
2 years ago Commented by: asantoni Date: 2010-08-23T04:46:31Z
FWIW the patch worked for me on latest 1.8, though:
alb@jupiter:~/Projects/mixxx-1.8$ patch -p0 < /home/alb/Downloads/cd0vGzR5.txt
(Stripping trailing CRs from patch.)
patching file mixxx/src/analyserbpm.cpp
(Stripping trailing CRs from patch.)
patching file mixxx/src/analyserwaveform.cpp
(Stripping trailing CRs from patch.)
patching file mixxx/src/analyserwavesummary.cpp
(Stripping trailing CRs from patch.)
patching file mixxx/src/library/dao/cuedao.cpp
(Stripping trailing CRs from patch.)
patching file mixxx/src/library/dao/trackdao.cpp
(Stripping trailing CRs from patch.)
patching file mixxx/src/soundsourcemp3.cpp
(Stripping trailing CRs from patch.)
patching file mixxx/src/trackinfoobject.cpp
(Stripping trailing CRs from patch.)
patching file mixxx/src/waveform/waveformrenderer.cpp
patch unexpectedly ends in middle of line
Hunk mixxxdj/mixxx#4910 succeeded at 496 with fuzz 1.With RJ's patch, I don't get xruns on track loads, though I didn't do great A-B testing here. I tested at 5 ms on a 3 GHz C2D (E8500) and also with it clocked down the 2 GHz, which is the lowest it'll go.
(I still get the usual assortment of insane other Linux xruns during regular playback, such as the ones caused by my wireless network driver. Ubuntu 9.10 with stock kernel. )
Albert
On Sun, Aug 22, 2010 at 9:45 PM, Albert Santoni
FWIW the patch worked for me on latest 1.8, though:
alb@jupiter:~/Projects/mixxx-1.8$ patch -p0 < /home/alb/Downloads/cd0vGzR5.txt (Stripping trailing CRs from patch.) patching file mixxx/src/analyserbpm.cpp (Stripping trailing CRs from patch.) patching file mixxx/src/analyserwaveform.cpp (Stripping trailing CRs from patch.) patching file mixxx/src/analyserwavesummary.cpp (Stripping trailing CRs from patch.) patching file mixxx/src/library/dao/cuedao.cpp (Stripping trailing CRs from patch.) patching file mixxx/src/library/dao/trackdao.cpp (Stripping trailing CRs from patch.) patching file mixxx/src/soundsourcemp3.cpp (Stripping trailing CRs from patch.) patching file mixxx/src/trackinfoobject.cpp (Stripping trailing CRs from patch.) patching file mixxx/src/waveform/waveformrenderer.cpp patch unexpectedly ends in middle of line Hunk #1 succeeded at 496 with fuzz 1.
With RJ's patch, I don't get xruns on track loads, though I didn't do great A-B testing here. I tested at 5 ms on a 3 GHz C2D (E8500) and also with it clocked down the 2 GHz, which is the lowest it'll go.
(I still get the usual assortment of insane other Linux xruns during regular playback, such as the ones caused by my wireless network driver. Ubuntu 9.10 with stock kernel. )
Albert
On Sun, Aug 22, 2010 at 3:52 PM, Robelix
wrote: same result with bzr version, the patch fails.
-- audio xruns on track load (1.8.0beta1) 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: roland-robelix Date: 2010-08-23T10:21:43Z
Tried again with a fresh checkout - no luck ;(
dings ~ # mkdir mixxx
dings ~ # cd mixxx/
dings mixxx # bzr checkout lp:mixxx/1.8
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data. See "bzr help launchpad-login".
dings mixxx # ls -lh
total 4.0K
drwxr-xr-x 11 root root 4.0K Aug 23 12:13 1.8
dings mixxx # wget http://pastebin.com/download.php?i=cd0vGzR5
--2010-08-23 12:16:03-- http://pastebin.com/download.php?i=cd0vGzR5
Resolving pastebin.com (pastebin.com)... 173.236.86.29
Connecting to pastebin.com (pastebin.com)|173.236.86.29|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11029 (11K) [application/download]
Saving to: `download.php?i=cd0vGzR5'100%[================================================================================================================================>] 11,029 48.1K/s in 0.2s
2010-08-23 12:16:03 (48.1 KB/s) - `download.php?i=cd0vGzR5' saved [11029/11029]
dings mixxx # cd 1.8/
dings 1.8 # patch -p0 < ../download.php\?i\=cd0vGzR5
patching file mixxx/src/analyserbpm.cpp
Hunk mixxxdj/mixxx#4910 FAILED at 44.
Hunk mixxxdj/mixxx#4911 FAILED at 72.
2 out of 2 hunks FAILED -- saving rejects to file mixxx/src/analyserbpm.cpp.rej
patching file mixxx/src/analyserwaveform.cpp
Hunk mixxxdj/mixxx#4910 FAILED at 53.
Hunk mixxxdj/mixxx#4911 FAILED at 108.
2 out of 2 hunks FAILED -- saving rejects to file mixxx/src/analyserwaveform.cpp.rej
patching file mixxx/src/analyserwavesummary.cpp
Hunk mixxxdj/mixxx#4910 FAILED at 77.
1 out of 1 hunk FAILED -- saving rejects to file mixxx/src/analyserwavesummary.cpp.rej
patching file mixxx/src/library/dao/cuedao.cpp
Hunk mixxxdj/mixxx#4910 FAILED at 228.
Hunk mixxxdj/mixxx#4911 FAILED at 244.
2 out of 2 hunks FAILED -- saving rejects to file mixxx/src/library/dao/cuedao.cpp.rej
patching file mixxx/src/library/dao/trackdao.cpp
Hunk mixxxdj/mixxx#4910 FAILED at 101.
Hunk mixxxdj/mixxx#4911 FAILED at 316.
Hunk mixxxdj/mixxx#4912 FAILED at 343.
Hunk mixxxdj/mixxx#4913 FAILED at 489.
Hunk mixxxdj/mixxx#4914 FAILED at 556.
Hunk mixxxdj/mixxx#4915 FAILED at 719.
6 out of 6 hunks FAILED -- saving rejects to file mixxx/src/library/dao/trackdao.cpp.rej
patching file mixxx/src/soundsourcemp3.cpp
Hunk mixxxdj/mixxx#4910 FAILED at 26.
Hunk mixxxdj/mixxx#4911 FAILED at 37.
Hunk mixxxdj/mixxx#4912 FAILED at 139.
Hunk mixxxdj/mixxx#4913 FAILED at 147.
Hunk mixxxdj/mixxx#4914 FAILED at 524.
Hunk mixxxdj/mixxx#4915 FAILED at 600.
Hunk mixxxdj/mixxx#4916 FAILED at 626.
Hunk mixxxdj/mixxx#4917 FAILED at 638.
Hunk mixxxdj/mixxx#4918 FAILED at 688.
Hunk mixxxdj/mixxx#4919 FAILED at 715.
10 out of 10 hunks FAILED -- saving rejects to file mixxx/src/soundsourcemp3.cpp.rej
patching file mixxx/src/trackinfoobject.cpp
Hunk mixxxdj/mixxx#4910 FAILED at 273.
1 out of 1 hunk FAILED -- saving rejects to file mixxx/src/trackinfoobject.cpp.rej
patching file mixxx/src/waveform/waveformrenderer.cpp
patch unexpectedly ends in middle of line
Hunk mixxxdj/mixxx#4910 FAILED at 496.
1 out of 1 hunk FAILED -- saving rejects to file mixxx/src/waveform/waveformrenderer.cpp.rej
dings 1.8 # Commented by: d00guan Date: 2010-08-23T21:14:48Z
Patching worked for me with patch -p0 < patch.diff in 1.8 folder.For me it didn't do much improvement I'm sad to say. Maybe it's a tiny bit better, but I still get xruns often with rt-kernel, and can produce them with ck-preemptive kernel, but only if I load a few tracks rapidly after one another.
My setup is stable enough now, but the performance boost came mainly from using ck-preemptive instead of rt kernel from UbuntuStudio ppa.
mixxxbot
commented
2 years ago Commented by: danielhjames Date: 2010-08-24T10:17:32Z
Hi Albert, in reply to your comment #26, yes, the rtlimits are fully tweaked. I can run other CPU intensive JACK applications without xruns at the same buffer settings, so I don't think this is a system bug.
I no longer believe this is BPM detection related, because it happens even with previously analysed tracks. Subjectively, I'd say it's less noticeable when using JACK than when going direct to ALSA, but it's still there.
I followed RJ's suggestion of piping output to /dev/null like this:
$ mixxx > /dev/null 2>&1I'm not getting xruns, but I am still hearing the glitch when loading the second track. It doesn't matter if it's dragged and dropped or added with a right-click from the Library. So I'll try RJ's patch next.
Cheers!
Daniel
mixxxbot
commented
2 years ago Commented by: danielhjames Date: 2010-08-24T11:54:49Z
More info - I can't reproduce this problem on a stock Lucid system, even when running through Pulseaudio at 2ms. The original poster is running Karmic and I can definitely reproduce it there. So is this due to some bug in a Karmic version of a library and not Mixxx at all?
Anders, I think you have a different problem with your JACK performance. Which soundcard are you using?
mixxxbot
commented
2 years ago Commented by: d00guan Date: 2010-08-24T13:34:34Z
I'm using the card in my Hercules RMX. It's a generic usb sound device.
Is there any way to test the performance of a soundcard with alsa?
mixxxbot
commented
2 years ago Commented by: danielhjames Date: 2010-08-24T13:57:26Z
Update: I can reproduce this bug on Lucid by killing Pulseaudio, running jackd and connecting Mixxx to jackd - the glitch on track load comes back. Stop jackd, start Pulseaudio and connect Mixxx to that instead, the glitch goes away. Same if I stop Pulseaudio and connect direct to ALSA.
However, if I install Mixxx 1.7.2 on the same system, the bug does not appear at high JACK buffer sizes such as 512 x 3. It does appear at 256 x 2 on the stock Ubuntu kernel.
mixxxbot
commented
2 years ago Commented by: danielhjames Date: 2010-08-24T14:52:19Z
Hi Anders, as you have a USB device, try:
jackd -R -t5000 -dalsa -dhw:1 -r44100 -p256 -n3
Some USB devices are just not happy with -n2. Going to -n3 will increase latency, of course. See also:
http://alsa.opensrc.org/index.php/Usb-audio#Tuning_USB_devices_for_minimal_latencies
There is a latency testing tool here: ftp://ftp.suse.com/pub/people/tiwai/latencytest/
mixxxbot
commented
2 years ago Commented by: d00guan Date: 2010-08-24T21:05:33Z
I tested updating to latest pulseaudio today, no ral improvement there. my previous version was one of the latest anyway.
I've tested running with 3 buffers before, and tried today but this don't give any improvement for me.
Tested setting nrofpacks, as recommended on the alsa link. No real improvement there.
I couldn't get latencytest to run. It's quite old and is missing things in my kernel.
I can indeed run Mixxx with ALSA directly and achieve latency around 5ms without much glitches, on both kernels. When they occur it's at track load. XRuns are definitely easier to reproduce with Jack. With ck-preemptive kernel and jack Mixxx is quite stable at 11.6ms latency. Same here, glitches occur at track load if the occur. I can even start Firefox and Eclipse while playing without glitches.
mixxxbot
commented
2 years ago Commented by: danielhjames Date: 2010-08-26T10:11:49Z
I've done some more testing on a stock Lucid amd64 system using a fresh checkout from Mixxx bzr built with:
sudo scons prefix=/usr install tuned=1 debug=0 qdebug=0
So all debugging messages are turned off. The track load glitch is still audible with JACK at 256 x3, so debugging messages aren't the cause.
What I have discovered is that loading a FLAC file is likely to trigger an audible glitch, reported as an xrun by JACK, while loading a WAV does not. It doesn't matter if the track already playing is a FLAC or a WAV. So is it the overhead of decoding a FLAC that's the real cause of this?
Cheers!
Daniel
mixxxbot
commented
2 years ago Commented by: ywwg Date: 2010-09-10T14:25:43Z
I think I can second RJ's conclusion above: any qdebug statement, even if it's piped to /dev/null, can cause major xruns. For instance there's one in cachingreader.cpp that reports when there's a cache miss -- removing that debug statement eliminated my xruns. So any qdebug in the audio processing thread has the potential to cause xruns.
Here's my recommendation: 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.
I'm not sure how to use scons, but I can help putting in #ifdefs
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).