Constant CPU load, even when playback is paused

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Just start squeezelite
2. Don't play anything, so in case something is playing stop it.

What is the expected output? What do you see instead?
No CPU load at all when no audio is playing. However there is still the same 
constant 10% CPU load, even when nothing is played back. By changing the output 
I can reduce the CPU load, but still the load won't change when playing back 
audio compared to when paused.

What version of the product are you using? On what operating system?
Ubuntu, x86-64, squeezelite 1.1

Please provide any additional information below.

Original issue reported on code.google.com by christia...@gmail.com on 3 Jul 2013 at 8:59

[GoogleCodeExporter]

suspect the output thread is spinning faster than necessary - can you enable -d 
output=sdebug to see what the log messages are?

Original comment by trio...@btinternet.com on 3 Jul 2013 at 9:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I did now compile squeezelite from the sources, but I still see the same effect.
Attached you will find two logfiles for two different audio outputs that I 
generated using the binary download from 
https://code.google.com/p/squeezelite/downloads/list running
./squeezelite-x86-64 -o sysdefault:CARD=PCH -n "cS.x121e" -d output=sdebug -f 
debug1.log
and
./squeezelite-x86-64 -o default -n "cS.x121e" -d output=sdebug -f debug2.log

As you will see from the logfiles I did start and stop the playback using the 
Squeezbox Server interface a couple of times.

Thank you for this great program!

Original comment by christia...@gmail.com on 3 Jul 2013 at 9:40

Attachments:

• debug1.log
• debug2.log

[GoogleCodeExporter]

Looks like at least one of those cases is doing sample rate conversion in the 
alsa layer.  Could you try with hw:CARD=PCH as the output?  Does this work at 
the rate of your source files?

Original comment by trio...@btinternet.com on 3 Jul 2013 at 9:48

[GoogleCodeExporter]

./squeezelite-x86-64 -o hw:CARD=PCH -n "cS.x121e" -d output=sdebug -f debug3.log
gave me the log file that I attached. The file that I played back was a 44100Hz 
FLAC file.

I was just wondering why the output thread has to do something even when there 
is silence.

Original comment by christia...@gmail.com on 3 Jul 2013 at 10:26

Attachments:

• debug3.log

[GoogleCodeExporter]

Squeezelite sends silence to the output device when not playing anything - this 
prevents clicks and pops opening and closing the device.  So I would expect to 
see the cpu load from the output thread to be constant - however 10% is a high 
value - what is the processor - is it always resampling?

Original comment by trio...@btinternet.com on 4 Jul 2013 at 8:12

[GoogleCodeExporter]

The processor is just a slow AMD E-350. Again, I was not trying to tell you 
about the 10%, but about the fact that the load does not change when paused. 
E.g. I am thinking about running squeezelite on a 24/7 machine, that acts as 
XBMC and squeezebox machine. However I want it to almost idle when not used, 
and squeezelite should not steal power from XMBC when not used at all.

Thank you very much for looking into my comment in such detail!

Original comment by christia...@gmail.com on 8 Jul 2013 at 7:04

[GoogleCodeExporter]

If you make the alsa buffer values bigger eg "-a 200" then it may reduce the 
cpu load in the output thread as it will wake less often.  However it will 
still keep the output device open and send silence to it, so will still needs 
some cpu (normally this registers as very little)

Original comment by trio...@btinternet.com on 8 Jul 2013 at 8:55

[GoogleCodeExporter]

I had the same issue on a MK802 arm device running linaro while sending the 
output to hw or plughw. After re-routing the output to dmix, the cpu usage went 
down to below 5%.

Original comment by sebastie...@gmail.com on 21 Aug 2013 at 3:01

[GoogleCodeExporter]

I had similar issue running on raspberry pi, squeezeplug version 6 (raspbian 
hard float). While paused squeezelite uses ~20% CPU usage. I've tried with both 
0.98 shipped with squeezeplug dist and latest 1.3 version of squeezelite.
Setting output to dmix seems to solve the issue (-o dmix). CPU usage is ~2-3% 
with dmix.

Turning the player off always drops CPU usage down to 0-1%.

Original comment by e28.bee...@gmail.com on 7 Oct 2013 at 9:50

[GoogleCodeExporter]

DMIX output worked for me, but it resulted in a playback that was too fast on 
an armhf platform similar to the raspberry pi. After much testing, I found that 
some cheap USB based sound cards have a chipset.

For example, the following device (lsusb) was playing too fast on dmix
0c76:1607 JMTek, LLC. audio controller

while the following didn't and is playing perfectly well
0d8c:000e C-Media Electronics, Inc. Audio Adapter (Planet UP-100, Genius G-Talk)

Original comment by sebastie...@gmail.com on 23 Oct 2013 at 8:26

[GoogleCodeExporter]

If using dmix results in playback that is too fast, using option '-u hLX' 
resamples the audio to the highest rate supported by the card, and still yields 
much lower CPU usage than sending the audio through pulseaudio.

It seems that upsampling with option -u isn't supported on some of the arm or 
mips binaries though. But if option -u does work, IMO it's a cleaner fix to 
have squeezelite resample than it is to get LMS or ALSA to do it.

Original comment by paul.w.c...@gmail.com on 25 Oct 2013 at 5:15

[GoogleCodeExporter]

I could not try -u hLX option as the available squeezelite binary for armhf 
only has the following options enabled:  LINUX ALSA EVENTFD.

Since I could not file libsox for that architecture, I can't compile it 
myself...  

There was an arm version of libsox in the following thread
http://forums.slimdevices.com/showthread.php?97046-Announce-Squeezelite-a-small-
headless-squeezeplay-emulator-for-linux-(alsa-only)&p=752342&viewfull=1#post7523
42

but trying to install it resulted in the following error
dpkg: error processing libsoxr0_0.1.1-1_i386.deb (--install):
 package architecture (i386) does not match system (armhf)
dpkg: error processing libsoxr-dev_0.1.1-1_i386.deb (--install):
 package architecture (i386) does not match system (armhf)
dpkg: error processing libsoxr-lsr0_0.1.1-1_i386.deb (--install):
 package architecture (i386) does not match system (armhf)
Errors were encountered while processing:
 libsoxr0_0.1.1-1_i386.deb
 libsoxr-dev_0.1.1-1_i386.deb
 libsoxr-lsr0_0.1.1-1_i386.deb

I am running this squeezelite on the following release
 sudo cat *-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.10
DISTRIB_CODENAME=quantal
DISTRIB_DESCRIPTION="Ubuntu 12.10"
NAME="Ubuntu"
VERSION="12.10, Quantal Quetzal"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu quantal (12.10)"
VERSION_ID="12.10"

Original comment by sebastie...@gmail.com on 27 Oct 2013 at 8:49

[GoogleCodeExporter]

I tried also to get around the high idle cpu load (plug is different to dmix 
and is different to route).
But I wasn't able to use dmix, because I'm using a 7.1 usb-soundcard and split 
it to separate channels using the pcm type plug.

Like this: pcm.sound_usb -> dmix -> softvol -> plug -> route

Output plug:  idle is about 12%, playing is not much more.
Output route: idle is 4%, playing is 7%
Output dmix:  idle is only 0-1%

Original comment by tobi.b...@googlemail.com on 24 Nov 2013 at 1:28

[GoogleCodeExporter]

Hi again...
I found a solution for my high cpu idle usage from this night.
I noticed now, the playback speed was too high (and also pitch). I checked the 
asound.conf and I saw, I used a rate of 48000. After changing it to 44100 the 
playback speed was normal and the cpu load is the same as using route.

So now it is: pcm.sound_usb -> dmix -> softvol -> plug
Output route: idle is 4-5%, playing is 8% (each instance; even if 4 players in 
sync)

Original comment by tobi.b...@googlemail.com on 24 Nov 2013 at 5:14

[GoogleCodeExporter]

Tobi, you're awesome!

I just changed the default rate in /usr/share/alsa/alsa.conf to 44100 and now 
dmix has the right pitch and the CPU usage is back to 4% on my little RK3066 
arm processor when idle, even on a cheap dongle.  This solution is very good 
timing as I just received a $15 usb card with SPDIF output that I was planning 
on using, and it was also causing high CPU.

I hope this helps others having the same issue!

Thanks!

Original comment by sebastie...@gmail.com on 4 Dec 2013 at 9:03

[GoogleCodeExporter]

Closing as this issue appears to be related to cpu caused by resampling in the 
alsa layer.  The latest 1.4 beta version will give more resampling option if 
libsoxr is installed, but otherwise it is important to make sure that you alsa 
configuration doesn't resample all the time on low performance machines as 
squeezelite will send audio silence all the time it is running.

Original comment by trio...@btinternet.com on 23 Dec 2013 at 10:47

• Changed state: WontFix

[GoogleCodeExporter]

Tobi, 

Could you post your asound.conf file? I am trying to do the exact same thing 
with splitting an 8 channel sound card into 4 stereo streams. It works fine, 
except for the high CPU use. 

I'm not quite sure how to accomplish this: pcm.sound_usb -> dmix -> softvol -> 
plug

Any help would be greatly appreciated!

Original comment by J...@milehighautomation.com on 29 Sep 2014 at 7:51

[GoogleCodeExporter]

Hey, here`s my asound.conf
Note: Perhaps there is some unseless stuff, but it works :-)
------------------------------------------

pcm.sound_internal {
         type hw
         card 0
         device 0
}

ctl.sound_internal {
         type hw
         card 0
         device 0
}

pcm.sound_usb {
        type hw
        card 1
        device 0
}

ctl.sound_usb {
        type hw
        card 1
        device 0
}

pcm.dmixer {
    type dmix
    ipc_key 1024
    ipc_perm 0666
    slave.pcm "sound_usb"
    slave {
        period_time 0
        period_size 1024
        buffer_size 4096
#        rate 96000
#       rate 48000      #was with the use of mpd
        rate 44100      #low cpu-load with squeezelite
        channels 8
    }
    bindings {
        0 0
        1 1
        2 2
        3 3
        4 4
        5 5
        6 6
        7 7
    }
}

################################################
# Hier kommen die Software-Mixer (Room Volume) #
################################################

pcm.softvol_room1 {
    type softvol
    slave.pcm "dmixer"
    control {
        name "Diele"
        card 1
    }
}

pcm.softvol_room2 {
    type softvol
    slave.pcm "dmixer"
    control {
        name "WC"
        card 1
    }
}

pcm.softvol_room3 {
    type softvol
    slave.pcm "dmixer"
    control {
        name "Bad"
        card 1
    }
}

pcm.softvol_room4 {
    type softvol
    slave.pcm "dmixer"
    control {
        name "Wohnzimmer"
        card 1
    }
}

pcm.!default {
    type plug
    slave.pcm "dmixer"
}

pcm.stereo1 {
    type plug
    slave {
        pcm "dmixer"
        channels 8
    }
    ttable.0.0 1
    ttable.1.1 1
}

pcm.stereo2 {
    type plug
    slave {
        pcm "dmixer"
        channels 8
    }
    ttable.0.2 1
    ttable.1.3 1
}

pcm.stereo3 {
    type plug
    slave {
        pcm "dmixer"
        channels 8
    }
    ttable.0.4 1
    ttable.1.5 1
}

pcm.stereo4 {
    type plug
    slave {
        pcm "dmixer"
        channels 8
    }
    ttable.0.6 1
    ttable.1.7 1
}

### My Setup for Mulirooming
#Diele      - room1  - GREEN (Front)            MONO    - left channel
#WC         - room2  - GREEN (Front)            MONO    - right channel
#Bad        - room3  - BLACK  (Surround)        STEREO
#Wohnzimmer - room4  - YELLOW (Bass/Center)     STEREO

#Diele
pcm.room1 {
    type plug
    slave {
       ###pcm "dmixer"
          pcm "softvol_room1"
        channels 8
    }
    ttable.0.0 1        #front left   --> left   100%
    ttable.1.0 1        #front right  --> left   100%
}

#WC
pcm.room2 {
    type plug
    slave {
     ###pcm "dmixer"
        pcm "softvol_room2"
        channels 8
    }
    ttable.0.1 1        #front left   --> right  100%
    ttable.1.1 1        #front right  --> right  100%
}

#Bad
pcm.room3 {
    type plug
    slave {
     ###pcm "dmixer"
        pcm "softvol_room3"
        channels 8
    }
    ttable.0.6 1        #surround left   --> left   100%
    ttable.1.7 1        #surround right  --> right  100%
}

#Wohnzimmer
pcm.room4 {
    type plug
    slave {
     ###pcm "dmixer"
        pcm "softvol_room4"
        channels 8
    }
    ttable.0.2 1        #center   --> left   100%
    ttable.1.3 1        #bass     --> right  100%
}

pcm.dmixer_internal {
    type dmix
    ipc_key 1024
    ipc_perm 0666
    slave.pcm "sound_internal"
    slave {
        period_time 0
        period_size 1024
        buffer_size 4096
        rate 96000
        channels 2
    }
    bindings {
        0 0
        1 1
#        2 2
#        3 3
#        4 4
#        5 5
#        6 6
#        7 7
    }
}

pcm.internal {
    type plug
    slave {
        pcm "dmixer_internal"
        channels 2
    }
   ttable.0.1 1        #front left   --> right  100%
   ttable.1.1 1        #front right  --> right  100%
}

Original comment by tobi.b...@googlemail.com on 2 Oct 2014 at 5:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Awesome, thanks!

Original comment by J...@milehighautomation.com on 4 Oct 2014 at 7:20