[Announce] Squeezelite-X

[ralphy]

"When I tried "-a :1" I got no sound unless I also specify sampling format using "-a <f>", where <f> = 16|24|32."

The -a <f> is ONLY available when the output device is a file/stdout as described in the help message.

-a <f>		Specify sample format (16|24|32) of output file when using -o - to output samples to stdout (interleaved little endian only)

[Dmitry©]

The -a <f> is ONLY available when the output device is a file/stdout as described in the help message.

-a <f>		Specify sample format (16|24|32) of output file when using -o - to output samples to stdout (interleaved little endian only)

Hello Ralphy!

Can i choose the channel number of multichannel sound card with ASIO driver? Now works only 2 first channels.

Thank you!

[ralphy]

Hello Ralphy!

Can i choose the channel number of multichannel sound card with ASIO driver? Now works only 2 first channels.

Thank you!

No, that's not supported.

[fpo]

Hello, first post.

Thanks for SqueezeLite-X, good looking and very useful.

I'm experiencing Dropouts when listening to MP3 files served via LMS.
Seems like those dropouts that were reported earlier.
The problem seems to be with SqeezeLite running on Windows, not LMS.

I'm using SqueezeLite-X 2.7.11 and the embedded player is squeezelite-x64.exe version 1.9.8.1307
The process squeezelite-x64.exe runs about 10 threads.

Looking at the processes using Task-Manager, Process Monitor, Process Explorer and the like I can see the following sequence of events:

1. When starting a title cpu load is typically way below one percent.
2. After some time, one of the threads starts to produce 100% cpu time (on one logical core).
3. The music still plays for some time after this, then a dropout occurs, the music stops.
4. After about 20-30 seconds cpu load drops and music comes back.

During phase 2-4, when cpu load is 100%, about 97 to 98% is kernel time.
This looks like some kind of deadlock. It seems no data or not enough data from LMS is received during this time and, since the thread that feeds the output is still running, the input buffer gets starved.
When it is emptied the dropout occurs. There is still network activity (TCP send and receive), but it seems no data gets transfered.
Entering phase 4 the deadlook is remedied with a TCP disconnect followed by a TCP connect. Then data gets transfered and music resumes.

Is seems each title starts with a TCP disconnect followed by a TCP connect, so one needs a suitable long MP3 to see the effect.
The problems timing depends on the buffer size (-b <x>) and on the bitrate the MP3 is encoded with.
Using a 195kb/s VBR 6MB file (duration about 4 minutes) the blocking usually starts 1:30 to 3:00 into the title.
For -b 256 phase 3 is about 20 sec, after 48 sec the deadlock is resolved.
For -b 2048 phase 3 is about 93 sec, after 124 sec the deadlock is resolved.

I cloned squeezelite from github to look further into it but couldn't compile it via VS. Some source was missing.

A quick fix for me is -b 8192 or -b 16384. The problem then just doesn't show up.

[Peter Galbavy]

Looking at the processes using Task-Manager, Process Monitor, Process Explorer and the like I can see the following sequence of events:

1. When starting a title cpu load is typically way below one percent.
2. After some time, one of the threads starts to produce 100% cpu time (on one logical core).
3. The music still plays for some time after this, then a dropout occurs, the music stops.
4. After about 20-30 seconds cpu load drops and music comes back.

During phase 2-4, when cpu load is 100%, about 97 to 98% is kernel time.

I see the same, most days, and I have just assumed that it's the player crashing and the process being dumped by Windows. I have not reqported as I have not looked at it as closely as you and I also, possibly falsely, assumed someone else would report it and it would get fixed. Been happening for months for me.

[fpo]

I see the same, most days, and I have just assumed that it's the player crashing and the process being dumped by Windows. I have not reqported as I have not looked at it as closely as you and I also, possibly falsely, assumed someone else would report it and it would get fixed. Been happening for months for me.

The problem is obviously with Squeezelite (the player) not with Squeezelite-X (the UI). The problem with the player is discussed in this thread:
https://forums.slimdevices.com/showt...very-5-minutes

I posted this here just to point out that one may avoid running into the problem by using a bigger stream buffer size.
You can set this via Squeezelite-X settings by adding e.g. "-b 16384" to the commandline for Sqeezelite (not Squeezelite-X).

[rgdawson]

The problem is obviously with Squeezelite (the player) not with Squeezelite-X (the UI). The problem with the player is discussed in this thread:
https://forums.slimdevices.com/showt...very-5-minutes

I posted this here just to point out that one may avoid running into the problem by using a bigger stream buffer size.
You can set this via Squeezelite-X settings by adding e.g. "-b 16384" to the commandline for Sqeezelite (not Squeezelite-X).

Thanks, you guys for these posts. I suppose I could have SLX include this setting "-b 16384" by default if not otherwise specified. Any downside to doing that?

As a reminder for others, you can include this setting via SLX as shown below.



R Greg Dawson

[fpo]

...
I suppose I could have SLX include this setting "-b 16384" by default if not otherwise specified. Any downside to doing that?
...

It is just a workaround, so may not applicable for all. Setting a big buffer will increase the working set size of the windows executable, i.e. consumes more memory. Easy to see with Windows Taskmanager.

There seems to be progress in understanding the underlying problem. I'm positive it may be soon resolved.

[rgdawson]

It is just a workaround, so may not applicable for all. Setting a big buffer will increase the working set size of the windows executable, i.e. consumes more memory. Easy to see with Windows Taskmanager.

There seems to be progress in understanding the underlying problem. I'm positive it may be soon resolved.

I see what you mean

R Greg Dawson

[TomS]

First, let me say I am new to Squeezelite(-X) and love it. I am using it as a controller only (no player). It is really great to have a tray icon for quick access to control things.

Two asks:

-Let's say I leave the window open, and it gets hidden behind other windows - when I right-click on the tray icon to say skip a track, it always brings the bigger windows to the front. That is not preferred (by me anyway) - I right-clicked to get to quick menu, not the big window. Any chance that behavior can change? Left click opens big window (or brings it to front), right click just brings up the quick menu (and does not bring big window to front if already open).

-Just putting my vote in for "hover over tray icon - see track/artist".

Thanks,

TomS