Output to null results in HIGH cpu load

[GoogleCodeExporter]

What steps will reproduce the problem?
1. squeezelite -l shows "null" device
2. squeezelite -n test -o null -d all=info
3. "top" in another shell shows 96% cpu load 
Procedure tested on x86-64 and armv5te executable
Output to pulseaudio results in much lower cpu load

What is the expected output? What do you see instead?
Expected Output would be low cpu load.

What version of the product are you using? On what operating system?
Version 1.1, Linux x86-64, armv5te

Background:
I would like to have a software squeeze player to be able to feed the stream 
from the server to a DLNA Renderer. Is there maybe a simple way to bypass all 
output and transcoding stuff in squeezelite? Thank you.

Original issue reported on code.google.com by helge.l...@gmail.com on 16 Apr 2013 at 2:35

[GoogleCodeExporter]

The alsa null output is not a useful output to select for squeezelite.  I agree 
it gives 100% cpu load, but this is not something squeezelite is designed to 
use as I don't see any useful use of it..  What is happening is that the null 
output accepts audio as fast as squeezelite can send it, so it keeps looping 
sending it.

I'm afraid squeezelite is designed to use alsa or port audio at present, 
there's no support for other output at this time such as DLNA.  Have you tried 
the server DLNA support.

Original comment by trio...@btinternet.com on 16 Apr 2013 at 7:33

• Changed state: WontFix

[GoogleCodeExporter]

The same happens for bluetooth speakers.
I configured them as a device in alsa and aplay works fine.
squeezelite -l shows the device as expected.
However, squeezelite -o BTSPEAKER will result in 99% cpu load.

Is there any possibility to fix this?

Original comment by robert00...@gmail.com on 30 Dec 2013 at 12:26

[GoogleCodeExporter]

squeezelite has an output thread which sends data to the device at the rate the 
device wants it, if the device does not cause snd_pcm_wait to wait then it will 
spin.  

Can you run with -d output=sdebug and post what the debug is?  I suspect the 
output device is consuming all the data without waiting.

Original comment by trio...@btinternet.com on 30 Dec 2013 at 10:32

[GoogleCodeExporter]

Sure, thank you!
Cmd was:

./squeezelite-armv6hf -n Box -o btboxx -d output=sdebug -f sl.log

I attached the first few lines from that log, since the error is written over 
and over again until I stop the process.

[11:37:43.768171] output_thread:534 start error: File descriptor in bad state
[11:37:43.768361] output_thread:534 start error: File descriptor in bad state
[11:37:43.768547] output_thread:534 start error: File descriptor in bad state

I reconfirmed that audio is working via

aplay -D btboxx /path/to/some/file.wav

Original comment by robert00...@gmail.com on 30 Dec 2013 at 10:48

Attachments:

• squeezelite.log

[GoogleCodeExporter]

ok I can avoid the 100% cpu for that case, but it means that the output device 
is not working correctly.  It is trying to reopen the device all the time.

Try without mmap: add "-a :::0" to the command line

Original comment by trio...@btinternet.com on 30 Dec 2013 at 4:47

[GoogleCodeExporter]

With -a :::0 the reopening is gone. See the new log.

However it still goes straigt to 100% so I can't really test the audio output. 
But the short popping noise when starting or stopping squeezelite sounds 
promising. :)

Original comment by robert00...@gmail.com on 30 Dec 2013 at 5:01

Attachments:

• squeezelite2.log

[GoogleCodeExporter]

Try it in 16 output mode "-a ::16:0"

Original comment by trio...@btinternet.com on 30 Dec 2013 at 5:11

[GoogleCodeExporter]

I just realized, that I've left out the output device -o. I reconfigured alsa 
to use the bt speakers as default, so this should be the same as -o btboxx.
But if I add -o btboxx, cpu load stays at 1-5% (which is ok for an RPi I think).

So, in short:
./squeezelite-armv6hf -n Box -d output=sdebug -f sl.log -a :::0
with alsa configured so that btboxx is the default audio device -> 100%

./squeezelite-armv6hf -n Box -o btboxx -d output=sdebug -f sl.log -a :::0
which should be the same -> ~ 5%

But playback was stuttering every now and then and playback stopped after some 
time.
I tried -a ::16:0 which seems to fix the stuttering. See the attached log for a 
complete start -> play -> stop -> switch off cycle.

Now my last problem is, that playback suddenly stops after some time. To be 
precise, LMS is still playing, the player is still connected, but sound is 
gone. In the logfile is nothing noticeable. I have to restart squeezelite to 
make it work again. This could be related to the bluetooth connection itself.

Thank you very much for your help so far!

Original comment by robert00...@gmail.com on 30 Dec 2013 at 6:54

Attachments:

• squeezelite4.log