Extreme CPU usage on linux

Bug #1414868 reported by naught101
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Expired
High
Unassigned

Bug Description

Currently, I have Mixxx open, with tracks loaded, but not playing anything. The CPU usage is sitting at over 200%:

top - 13:54:10 up 1:50, 6 users, load average: 6.86, 5.07, 4.25
Tasks: 332 total, 3 running, 328 sleeping, 0 stopped, 1 zombie
%Cpu(s): 44.9 us, 5.1 sy, 0.0 ni, 42.6 id, 7.3 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 8087684 total, 7768972 used, 318712 free, 304856 buffers
KiB Swap: 15359996 total, 0 used, 15359996 free. 2473232 cached Mem

  PID PPID UID USER RUSER TTY NI TIME+ %CPU %MEM S COMMAND
13488 5644 1000 naught1+ naught1+ ? 0 206:56.76 226.8 9.4 S mixxx
24482 24356 1000 naught1+ naught1+ ? 0 2:38.69 106.8 2.4 S BitwigStudioEng
24356 5644 1000 naught1+ naught1+ ? 0 0:57.85 35.8 5.0 S bitwig-studio
13849 5439 1000 naught1+ naught1+ ? -11 3:02.57 11.3 0.2 S pulseaudio

When I have something playing, it sits well over 300%.

Computer specs: http://www.engadget.com/products/samsung/series-7/chronos/specs/

$ uname -a
Linux naught101-chronos 3.13.0-44-lowlatency #73-Ubuntu SMP PREEMPT Tue Dec 16 00:48:57 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Kubuntu 14.04.1 LTS

Mixxx was installed from source using `scons prefix=/usr/local faad=1 -j2 install` (so that I could have m4a/aac support)

This seems pretty intensive for something that's just playing music. Is this normal? If it's as extreme as it seems, let me know if I can provide any more information.

Revision history for this message
Owen Williams (ywwg) wrote :

Still happening? I don't see this, even with very small buffer sizes. Also what's your CPU? Also we've had bad experience with the "lowlatency" kernels, the default kernel works better, even at low latencies :)

Revision history for this message
naught101 (naught101) wrote :

Yep, still happening. Intel Core i7. I will try with the standard kernel.

Revision history for this message
Owen Williams (ywwg) wrote :

hm I also see that pulseaudio and bitwig are running. What sound settings are you using?

Revision history for this message
naught101 (naught101) wrote :

I was using mixxx via ALSA/Pulse, but the same performance problem occurs when I'm using the soundcard (hw:0,0) directly. And the CPU usage is high regardless of whether Bitwig is running - that was just there for comparison.

Revision history for this message
Owen Williams (ywwg) wrote :

Can you run mixxx with the --developer flag and then post your mixxx.log?

Revision history for this message
naught101 (naught101) wrote :

Attached. So, I just noticed that if I just start mixxx, CPU usage sits at ~40%. If I load a track in deck 1, it jumps to ~180%. If I load another track into deck2, it jumps to ~270%. This is without playing anything. If I eject the tracks from the decks, the CPU usage drops back down to ~50%. Perhaps this is related to waveform rendering?

Revision history for this message
naught101 (naught101) wrote :

Yep. If I set waveforms -> summary to "empty", then load tracks, Mixxx stays well below ~10% CPU. It's high when I use filtered (GL) or filtered (GLSL).

Revision history for this message
Owen Williams (ywwg) wrote :

yeah almost certainly waveforms. What's your video card / driver combo? Is there any GL-based waveform that doesn't result in a spike? How are the 2d waveforms?

Revision history for this message
Owen Williams (ywwg) wrote :

What skin are you using? I see a warning that "play_sync" doesn't exist, and this object does not appear in the current trunk builds.

Revision history for this message
naught101 (naught101) wrote : Re: [Bug 1414868] Re: Extreme CPU usage on linux

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Seymour [Radeon HD 6400M/7400M Series] [1002:6760] (prog-if 00
[VGA controller])
         Subsystem: Samsung Electronics Co Ltd Radeon HD 6490M [144d:c0b3]
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
         Latency: 0, Cache Line Size: 64 bytes
         Interrupt: pin A routed to IRQ 52
         Region 0: Memory at a0000000 (64-bit, prefetchable) [size=256M]
         Region 2: Memory at c0700000 (64-bit, non-prefetchable) [size=128K]
         Region 4: I/O ports at 3000 [size=256]
         Expansion ROM at c0720000 [disabled] [size=128K]
         Capabilities: <access denied>
         Kernel driver in use: radeon

All of the GL shaders cause increased CPU usage, to varying degrees
(e.g. at least ~160%).

Using LateNight, a build from git from about a month ago. I can update it.

On 03/02/2015 02:03 PM, Owen Williams wrote:
> yeah almost certainly waveforms. What's your video card / driver combo?
> Is there any GL-based waveform that doesn't result in a spike? How are
> the 2d waveforms?

> What skin are you using? I see a warning that "play_sync" doesn't
> exist, and this object does not appear in the current trunk builds.
>

Revision history for this message
Owen Williams (ywwg) wrote :

do you know which driver are you using, free or proprietary?

Revision history for this message
naught101 (naught101) wrote :

The open source radeon driver.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

naught101 -- does this still happen with Mixxx 2.1 or 2.2 beta?

Changed in mixxx:
importance: Undecided → High
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Mixxx because there has been no activity for 60 days.]

Changed in mixxx:
status: Incomplete → Expired
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.