[Announce] Squeezelite-X

[rgdawson]

Again, thanks all for reporting. I was not able to reproduce this last night, but today I tried again with "Run in Background" enabled and I was able to reproduce. Do you see the problem when "Run in Background" in not enabled? Maybe I just got lucky or maybe it is related.

[Edit]: Nevermind, I was able to reproduce with "Run in Background" disabled.

Right now, I can reproduce the problem depending on the Output Device selected. I cannot reproduce when "Primary Sound Driver [Windows Direct Sound]" is selected. Now, I am currently away from my home office, so I am using Remote Desktop and the Audio Devices appear different between being there and using Remote Desktop. So, I may be causing a similar problem a different way rather than the same problem, so I need to test some more from home. I'd like to know if the problem remains for you when using "Primary Sound Driver". (I'm assuming you are not using Remote Desktop, but if you are then we might be on the exact same page.)


R Greg Dawson

[rgdawson]

My working theory right now is that on resume, if 'Default' is selected for the audio output device, then squeezelite is being started up before the audio device has resumed from sleep and is ready. If a specific audio output device is selected then SLX polls to ensure that audio device is responding before starting squeezelite. But in the case of 'Default' it does not do that because SLX doesn't know what device squeezelite will select for default and therefore what to look for. The mistake is that, SLX still needs to wait. When squeezelite starts and cannot connect to an audio device, then it aborts and you see the "Check Squeezelite Parameters" error. So my next experiment will be to simply add some default wait time in that case.

Another (additional) case may be that the network connectivity has not resumed fully. SLX does poll and enumerate the network cards prior to reconnecting everything, but simply enumerating the cards to verify they are there may return true before the card has actually reconnected to the network. So, I am thinking that I may need to add/alter that check as well.

I'll have a fix.

In the meantime, I always recommend using "Primary Sound Driver" as your audio output device.

[bondsc]

My working theory right now is that on resume, if 'Default' is selected for the audio output device, then squeezelite is being started up before the audio device has resumed from sleep and is ready. If a specific audio output device is selected then SLX polls to ensure that audio device is responding before starting squeezelite. But in the case of 'Default' it does not do that because SLX doesn't know what device squeezelite will select for default and therefore what to look for. The mistake is that, SLX still needs to wait. When squeezelite starts and cannot connect to an audio device, then it aborts and you see the "Check Squeezelite Parameters" error. So my next experiment will be to simply add some default wait time in that case.

Another (additional) case may be that the network connectivity has not resumed fully. SLX does poll and enumerate the network cards prior to reconnecting everything, but simply enumerating the cards to verify they are there may return true before the card has actually reconnected to the network. So, I am thinking that I may need to add/alter that check as well.

I'll have a fix.

In the meantime, I always recommend using "Primary Sound Driver" as your audio output device.

I'm not using the "Primary Sound Driver".
I'm not using Remote Desktop to the PC, I'm at the console (although I do have many outgoing RDP connections from that PC).
I have many output audio devices and I've found that SLX seems to "lock" the chosen output device (I mentioned this back on the previous page) so I tend to use the following setup:

Laptop built-in audio - not used
Monitor built-in audio - not used
Plantronics Headphones - set as Windows default and used for web pages, Microsoft Teams
Asus Xonar U7 USB audio - this has two outputs: a) A 5.1 audio system and b) My music headphones. The Xonar chooses the output either by what I've plugged in or via a button. This is the audio device I've setup for SLX

The idea is that all "normal" audio goes to my Plantronics Headphones which I use for work.
Then all music is via SLX to either the 5.1 speakers (when I'm alone) or the music headphones (when others around).

It's a BIG list in SLX:



Simon

[rgdawson]

Does Squeezelite-X lock / gets exclusive access to any audio device it is using (on Windows)? I ask because, while I mainly use hardware players, I run SLX on a few Windows PCs and I've noticed that if I try and use the same audio device (usually headphones) from some other application (e.g. web browser) then I often have trouble getting the audio to work (silence) and often have to unplug / replug devices. When I then wish to continue playing music in SLX, it typically then doesn't play (silence again) and I have to edit the SLX settings to change to another audio device, apply, and then switch back to my headphones.
It's not that big an issue - I typically use one set of headphones for music (SLX) and the built-in audio speakers for web browsing - but I was just wondering if this behaviour was expected...

I never answered this... SLX uses/executes the squeezelite executable under the hood. SLX just passes the output device that you select as a parameter when starting squeezelite. My understanding is that squeezelite does not generally take exclusive access (although, if you know how, you can define specify though additional parameters that it does). I'd refer you to the squeezelite author, Ralphy, for more details. In my experience, when I bypass the Windows Primary Driver by selecting a specific output device in squeezelite, I have seen what you observe as well. I generally configure SLX to use Primary Windows Driver, then when I want to change to a different output device, I select that in the in the OS from the audio tray icon. That seems to work best and is the most stable (for me). That said, if you want to output to two devices separately and simultaneously as you describe in your most recent post, then you would want to select that specific output in SLX.

R Greg Dawson

[tw99]

I also had Default selected as the output device. I've now changed it to Primary Sound Driver, but I've also seen the same hang problem again when resuming from sleep...

[rgdawson]

I'm not using the "Primary Sound Driver".
I'm not using Remote Desktop to the PC, I'm at the console (although I do have many outgoing RDP connections from that PC).
I have many output audio devices and I've found that SLX seems to "lock" the chosen output device (I mentioned this back on the previous page) so I tend to use the following setup:

Laptop built-in audio - not used
Monitor built-in audio - not used
Plantronics Headphones - set as Windows default and used for web pages, Microsoft Teams
Asus Xonar U7 USB audio - this has two outputs: a) A 5.1 audio system and b) My music headphones. The Xonar chooses the output either by what I've plugged in or via a button. This is the audio device I've setup for SLX

The idea is that all "normal" audio goes to my Plantronics Headphones which I use for work.
Then all music is via SLX to either the 5.1 speakers (when I'm alone) or the music headphones (when others around).

It's a BIG list in SLX:



Simon

Thanks for the detail. I have only been able to reproduce a sleep/resume issue by RDP'ing into the PC running SLX and putting it to sleep while in the RDP session and using other than "Primary Sound Driver" and with the RDP session configured to play audio on the client. Then it awakes (not in RDP) and Windows has to sort out that audio mapping. For whatever reason, this reliably causes squeezelite to abort after a more than usual amount of time. (Perhaps it happens when Windows finally remaps the audio drivers from RDP-to-client back to local, I don't know). In any case, since I cannot reproduce this any other way, I used this scenario to rewrite the section of code where I detect something-gone-wrong-while-resuming and how to recover more automatically. There is a decent chance it will work for your scenario, because I might be sorta the same thing happening, but maybe for different reasons.

I intend to push out the update in the next day or two with this change after a bit more testing.

Btw, you can reduce the size of that list by disabling audio devices you do not use in Windows settings. For example you could disable the NVIDIA High Definition Audio device and maybe Realtek(R) and then they won't show up.

Lastly, for anyone reading this, I would recommend avoiding 'Default' for output device in SLX. This is squeezelite's default and what it selects when no output device is specified. In other words, if you select 'Default' SLX does not specify an output device to squeezelite and squeezelite picks one itself. If I knew how, I would have SLX default to 'Primary Sound Driver', but I don't know how this enumerates in languages other than english. squeezelite uses a library called PortAudio for its audio library, so I use it only to enumerate the available audio device strings so I can pass the correct string to squeezelite when it starts up. Right now, I don't know how to identify which one in the list is Primary Sound Driver (except in English).

R Greg Dawson

[rgdawson]

I also had Default selected as the output device. I've now changed it to Primary Sound Driver, but I've also seen the same hang problem again when resuming from sleep...

OK, thanks for letting me know. (I'm actually surprised by that, oh well.) I'm hoping the changes I have made will solve the problem in your scenario as well. I think squeezelite is aborting for some reason, possible because the available audio devices are changing underneath it as they all wake up on their own, though I would have thought Primary Sound Driver would insulate that from squeezelite. Anyway, the new code will detect recover better.

R Greg Dawson

[bondsc]

I never answered this... SLX uses/executes the squeezelite executable under the hood. SLX just passes the output device that you select as a parameter when starting squeezelite. My understanding is that squeezelite does not generally take exclusive access (although, if you know how, you can define specify though additional parameters that it does). I'd refer you to the squeezelite author, Ralphy, for more details. In my experience, when I bypass the Windows Primary Driver by selecting a specific output device in squeezelite, I have seen what you observe as well. I generally configure SLX to use Primary Windows Driver, then when I want to change to a different output device, I select that in the in the OS from the audio tray icon. That seems to work best and is the most stable (for me). That said, if you want to output to two devices separately and simultaneously as you describe in your most recent post, then you would want to select that specific output in SLX.

R Greg Dawson

Thanks for the explanation. Yes I have a maze of audio devices and I'll take your suggestion of disabling ones I don't use.
I plan to purchase another Raspberry PI (if I can ever find one), plug the Xonar USB sound card into that and run my music completely separately from my laptop. I was using a Squeezebox boom, but all my hardware players are now in use throughout the house.

[rgdawson]

Thanks for the explanation. Yes I have a maze of audio devices and I'll take your suggestion of disabling ones I don't use.
I plan to purchase another Raspberry PI (if I can ever find one), plug the Xonar USB sound card into that and run my music completely separately from my laptop. I was using a Squeezebox boom, but all my hardware players are now in use throughout the house.

I tried to find a R-Pi for a couple years. I would use this link almost every day to try to locate one: https://rpilocator.com/ I finally gave up and just went on e-Bay and paid 4x for one from a scalper. That is just the market. Good luck.

R Greg Dawson

[bondsc]

I tried to find a R-Pi for a couple years. I would use this link almost every day to try to locate one: https://rpilocator.com/ I finally gave up and just went on e-Bay and paid 4x for one from a scalper. That is just the market. Good luck.

R Greg Dawson

Yeah I've had a similar problem. All my PIs are currently in use (one converting USB to ANT+ for the bike trainer, one for OpenHAB, one in a robot etc) so for my latest solar project I used a BeagleBone Black, I'm looking at using a BeagleBone Enhanced, and I've also been looking at a RockPI for the next project.
The BeagleBones are pretty low voltage (similar to a PI Zero 2W in power usage) so useful in low power projects where the CPU power of a PI3 or 4 isn't required. Perfect for monitoring my solar system.
The ROCK PIs are expensive, but now the ROCK 5 is out, the 3 and 4 seem to have lowered in price. A ROCK 3 is more than enough for some of my use-cases (it's kind of half way between a PI 3B and PI4).
I've heard that the PI shortage will be sorted later this year, but no sign of that yet....

[staresy]

Greg,
Just a thought, if the MAI plugin is installed, when running Material skin, is it possible to make the "info" button available from the mini-player, perhaps by the volume slider or in the toolbar next to the full-screen buttons?

The idea being, pressing this would open the MAI info page in the main browser.

[rgdawson]

Greg,
Just a thought, if the MAI plugin is installed, when running Material skin, is it possible to make the "info" button available from the mini-player, perhaps by the volume slider or in the toolbar next to the full-screen buttons?

The idea being, pressing this would open the MAI info page in the main browser.

I'm afraid not. This idea presents several technical challenges and something would have to be implemented in both material skin and in SLX and new signaling between the two, so I think it is a no for now.

R Greg Dawson

[rgdawson]

New Version 2.11.52

Changes:

• Attempt to fix issues some are reporting on Sleep/Resume
• Added some parallel processing on startup to shave of a bit of time to start up (maybe a half second on some systems).

I just submitted, so it may take a day or two to get published through the MS Store. The traditional installer is available now, as usual.


Explanation of Resume Issue: After some testing I discovered that the Port Audio library used by squeezelite will return the list of output devices that existed when the computer went to sleep immediately upon wake. It takes some time before it is reliable to enumerate the audio devices. This I knew and prior I was waiting six seconds, then I would check the devices to confirm their presence. (For example a USB device may have been unplugged while the computer was asleep). When testing with RDP I also saw that it could take up to 20 seconds in my case for the audio devices to get remapped properly by the OS. My code was getting the list too early and the devices were still being reported as there, when they were not. Thinking they were there I would start squeezelite and it would try to connect to the audio device but would eventually abort (well after the window I was expecting). It is probably true that on some systems more than 6 seconds is needed. I finally just decided the best thing to do is wait longer on resume. I now wait 20 seconds before trying to start squeezelite.

R Greg Dawson

[bondsc]

New Version 2.11.52

Changes:

• Attempt to fix issues some are reporting on Sleep/Resume
• Added some parallel processing on startup to shave of a bit of time to start up (maybe a half second on some systems).

I just submitted, so it may take a day or two to get published through the MS Store. The traditional installer is available now, as usual.


Explanation of Resume Issue: After some testing I discovered that the Port Audio library used by squeezelite will return the list of output devices that existed when the computer went to sleep immediately upon wake. It takes some time before it is reliable to enumerate the audio devices. This I knew and prior I was waiting six seconds, then I would check the devices to confirm their presence. (For example a USB device may have been unplugged while the computer was asleep). When testing with RDP I also saw that it could take up to 20 seconds in my case for the audio devices to get remapped properly by the OS. My code was getting the list too early and the devices were still being reported as there, when they were not. Thinking they were there I would start squeezelite and it would try to connect to the audio device but would eventually abort (well after the window I was expecting). It is probably true that on some systems more than 6 seconds is needed. I finally just decided the best thing to do is wait longer on resume. I now wait 20 seconds before trying to start squeezelite.

R Greg Dawson

Great. Thanks!!
I've manually updated (work policy blocks the Windows store).
I'll let you know how it goes....

Simon

[rodlogic]

Hi,
Just updated to 2.11.52 from the Microsoft Store - When loading I get the error "One or more errors occurred" if I then hit Apply Squeezelite-X loads then crashes with the error

Access Violation at address 0000000001155FC4 in module " Squeezelite-X" . Read address 0000000000000018.

If I press Stop and Apply the same error occurs.

I will reboot and check again

[Edit]

Rebooting Windows 10 fixed this .