Mixxx Trunk has playback issues. Choppy sound, lagged waveform.

[TDJACR]

Using the current trunk branch, playback is choppy. The sound pops on a variety of set latencies and the waveform isn't smooth. I'm running ubuntu and didn't have this problem in 1.6

Loops aren't smooth, either, for apparently the same reason.

Other than that, keep up the great work!

[RJ Skerry-Ryan (rryan)]

Hi thedjatclubrock,

Could you check a couple things for me?

1) What version of Ubuntu are you using?
2) Make sure you have CPU Frequency Scaling turned off or set to 'Performance' mode.
3) Is this using 'Vinyl Emulation' mode or 'Pitch Independent Time Stretch' mode?
4) What soundcard are you using?
5) What latency are you using?
6) What graphics card do you have? Which driver are you using? (if you know)

Sorry for the barrage of questions :) and thanks for reporting your issue.

[TDJACR (thedjatclubrock)]

1) Karmic
2) Done
3) Pitch independant
4) Which ever one is in the newer MacBook Pro
5) I've tried a range from low to high. Sticking to 64
6) Nvidia restricted :/

No problem :) Keep up the good work.

[RAFFI TEA (raffitea)]

On my Kubuntu 9.10 (X64), Mixxx Trunk crashes whenever I use the *MOUSE* to drag the waveform rapidly back to an earlier point in time. This happens with MP3 and OGG files. MP4 files seem to work fine, at least for me.

I used Vinly Emulation Mode and a cheap USB sound card. Latency was set to 100ms. No MIDI, turntuables ... but Nvidia restricted.

I got the following debug error:

Fatal: []: ASSERT: "yv1[8]<100000 || yv1[8]>-100000" in file src/engine/enginefilteriir.cpp, line 59
Aborted

[RAFFI TEA (raffitea)]

Just forgot to mention that the corresponding deck was playing a song when I dragged the waveform back.

[RJ Skerry-Ryan (rryan)]

Hi all,

I just fixed a plethora of performance issues in trunk. Can you both please pull the latest fixes and try again?

Also, I should note that in Linux -- user programs cannot put priority on threads so Mixxx cannot mark the 'audio playback' thread as time critical. A quick workaround is to run Mixxx as root, via `sudo'. Another solution is to edit your /etc/security/limits.conf to allow your user to set the priorities.

Thanks,
RJ Ryan

[RAFFI TEA (raffitea)]

Dear all,

Mixxx 1.8 Beta 1 has still playback issues. Playing a song on Deck A while moving the waveform with the mouse of a (maybe playing) track on deck B, Mixxx is likely to produce an aweful playback noise. This is not always the case, however, it is very likely. Mixxx 1.7.x does not have such issues, at least on my systems.

This has been tested on Windows 7 x86: Dual Core 2 Duo, 1.66 Ghz, 2GB RAM, Audio 4 DJ (ASIO) , GeForce 7400 Go
This has also been tested on Windows XP SP3 x86: Core 3 Duo P9600, 2.66 GHz, 4 GB RAM, Audio 4 DJ (ASIO), GeForce 9300M

The latencies were set to between 1 to 5ms.

[RAFFI TEA (raffitea)]

Hi again.

some more notes about the playback issues:

On Windows I discovered that playback issues might be strongly related to ASIO. Regardless of the latency setting in Mixxx, I always hear noise or maybe interruptions during playback -- I don't use the mouse to drag the waveform this time. This happens at latencies from 5ms to over 100ms, but if I change the audio API to "Windows Direct Sound" all problems go away. But I want to use ASIO because of low latencies.

This has been tested with Mixx 1.8 Beta and current trunk (r2421) on Windows 7 x86: Dual Core 2 Duo, 1.66 Ghz, 2GB RAM, Audio 4 DJ (ASIO) , GeForce 7400 Go

r2421 was compiled against QT4.6.2 which seems to have OpenGL regression problems. Maybe it is a good idea to compile it against QT 4.5.3 and see if it solves our problem.

[RAFFI TEA (raffitea)]

If I compile against QT 4.6.3 the audio issues do not go away but it feels better. However, compiling against QT 4.5.3 solves my issue described in #7. Also, Mixxx 1.8.pre2 Beta runs much better on Win7 (x86) as on Windows XP. It seems to me that Windows 7 is optimised for multi-core applications. There is absolutely no noise during playback anymore but on XP there's still some little noise. I could observe same behaviour with Mixxx 1.7.x series on both systems always using same latency settings.

Thanks to Pegasus who pointed me in the right direction to solve my problems. Obviously, some of the playback issues have to do with QtOpenGL regressions introduced in QT 4.6.x

[gimmeapill (gimmeapill)]

Waveform display is still completely choppy in 1.8 trunk R2512.
Strangely it seems to change a bit according to the skin chosen

Here are the specs of my system:
HP Probook 5310m
Arch Linux i686
qt 4.6.3-1
X.Org X Server 1.8.1.902 (1.8.2 RC 2)
xf86-video-intel 2.12.0-1
fluxbox

[ironstorm (ironstorm-gmail)]

HP Probook 5310m might be a Celeron 1.2 GHz ULV (multicore?) or a Core2Duo 2.2, likely with 2GB of RAM

[gimmeapill (gimmeapill)]

Sorry for the late reply, I didn't get notified of your comment:
Core2 duo@2.2, 2GB of RAM - no CPU scaling enabled (quite a fast machine actually)

But nevermind: the latest performance fixes solved it, although I cannot tell which commit exactly.
As of trunk 1.8 R2845 - the waveform display is perfectly smooth with all the skins without dropout @ 5ms and CPU usage was cut by half (at least)

As far as I'm concerned, this one is fixed and performance is now very good - thx guys!

[RJ Skerry-Ryan (rryan)]

Tentatively marking Fix Committed. TDJACR, could you please test this and let us know if it improved your performance?

Thanks,
RJ

[jus (jus)]

Tested with current trunk

Looks like the waveform performance is tied to the latency setting.
Set the latency in Mixxx preferences high and the waveform lags. This is kinda problematic as the default setting for a fresh Mixxx installation is very generous (85 ms ?) . With OSX i get no smooth waveform over 10ms latency. I doubt that a new user get the idea to change the latency settings for smoother waveform performance.

[RJ Skerry-Ryan (rryan)]

It's true. The waveform only updates every time the engine processes data (which is the latency period), so a latency of 50ms is only 20 frames per second, and 85ms is only 11 frames per second. I think making the default latency lower is a good idea to give people a good impression on first run. A latency of 25ms will produce a 40fps waveform, which should be fairly smooth, or at least much smoother than at 50 or 85ms latency.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5232