Snapclient blocks soundcard/ALSA and stops playing after changing radio station #1249
Comments
|
This sounds a bit similar to #926, which was apparently resolved by changing mpd settings. However, I don't have mpd installed here. |
|
When I run It reports "waiting for chunk" very 2 seconds until I killed it with ^C. |
|
I did some more research, and even in the "stuck" state, I sometimes find "closing ALSA" in the log, but the card is does still not play using FYI, I used the same USB sound card when I tested this system on the Pi5, where the problem was not there. |
|
Interesting, the system seems to go bad on the restart of a new radio channel, not so much after stopping the previous station. Here is my reasoning: If I start a radio station after reboot, it plays music, and I can issue an aplay command, and it will play it on top of the playing radio music. If I stop the radio channel (say, by turning off the player), aplay still works. Only if I restart the radio with a different station, then there is no music, and aplay does not work any more. |
|
This looks rather like the server stops sending audio. Maybe music assistant stops feeding audio to the server. |
|
This is what the log looks like while it is playing normally (at 06:52:34 AM I stopped the player): |
|
I should also mention that I am using another snapclient in the same network without problems, which is why I am thinking the problem is on the side of the client described here. |
Hi @badaix ! Thanks so much for looking into this so quickly. Do you think it is possible that a problem on the server side would lead to aplay no longer working (actually freezing) on the client side? When things go well, I can run aplay even on top of the playing stream from the server, but when the problem occurs, aplay just stops working on the client side whatsoever. Not only is there no sound coming out of the system, but the aplay command actually never finishes and appears to be stuck. Also, this problem does not appear with another client. Obviously, the two clients could be sending something slightly different to the server, so that it only causes a problem with one client. I can even try with a third client. Any idea for how to further debug this? Server logs? |
|
On my installation, I am running Music Assistant as a container, which includes the snapcast server. I was poking around inside the container but wasn't able to find any snapserver logs. Snapserver inside the container seems to be running entirely with default settings; pretty much everything in |
|
Hi, 2024-07-24 22-28-55.459 [Debug] (Player) setVolume exp with base 10: 0.68 => 0.4207 |
I have a Pi 5 running Music Assistant. To test, I used a second Pi5 as client, which worked perfectly. For the final installation, I switched the client to a Pi Zero 2W, on which I am running a vanilla installation of Ubuntu 24.04 server.
Directly after booting the snapclient works well — until I change the radio station. Sometimes, I can change the station 2-3 times, sometimes, the problem will show up after changing the station for the first time: the player stops playing music, and it won't even make sounds following a simple
aplay -r 22050 -c 1 -f S16_LE Front_Right.wav(which works directly after boot). The command never finishes and is stuck.If I run a
journalctl -u snapclient.service -n 50, I get thisStrangely, in the case where ALSA ends up being blocked, the log looks almost the same, except that the last line with "Closing ALSA." is missing. Does that mean that ALSA is not properly released, and that is why no more sound can be played on this machine after? How can I force a release of ALSA?
Steps to Reproduce
Environment details
Logfile
When I do
snapclient --logfilter debugin "stuck" mode, I get this:The text was updated successfully, but these errors were encountered: