Max2Play Home › Forums › Max2Play as Squeezebox (Player / Server) › Multiroom system and player instabilities › Reply To: Multiroom system and player instabilities
Hi Mario,
I need some help to understand how the buffers works.
If I change these parameters in some combinations, Squeezelite does not start – a combination that works is 180:4:: but increasing too much cause players to not play at all. For instance 160:8:: does not works.
From the help is not clear how to distinguish between ms or bytes and how buffers are used to setup properly the params (with 80:4:: does it means the buffer is 80×4? 80 is ms or bytes? what happens if using more buffers? better to increase buffers or size, how to choose?)
I think that there should be some standard configs (or max supported) for the standard pi hardware, and I have not to guess.
Anyway to understand more about my problem I moved the Server from the Controller (RPi3+ in living room, closest to the main router) to the ClientOne on the 2nd floor (second Rpi3+), the farest client – the player on the controller is working as usual while the other two players continue to hang, even that one hosting the server (!) and killing pulseaudio service unlock the audio.
Everything is working on cable LAN, not WiFi.
So:
– even with the server on the same client with standard audio (headphone) the player hangs – need to kill pulseaudio to restart
– with crontab killing pulseaudio the audio is working but is out of sync
– tryed to disable pulseaudio service (systemctl –user stop pulseaudio.socket pulseaudio.service) but the audio still hangs and in this case I have nothing to kill… so the problem could be on ALSA layer since is the basic hardware control software
– killing pulseaudio should have some other effects to unlock the audio sync, but I’m pretty confident that is not pulseaudio the problem
– the only combination that is not experiencing problems is the streaming to bluetooth speaker – I see that in this case the player uses bluealsa, but apart this I do not know if bluealsa bypass the standard pulseaudio->alsa combination
– as a confirmation, if I disable all the player or exclude them from the synch group except the player streaming on bluetooth speaker with the server on any of the Rpi3+ (i miss only a test on Rpi2) everything works perfectly
– Changing params on Server side does not make any positive effects:
– increased the players latency
– increased the radio timeouts
– Used even the „local caching“ option, that in theory should write locally a buffer before streaming
It should be unlikely I’m the only one experiencing problems with standard hardware… is there any specific set of configs to adopt?
The last test I’m going to do is to use a bluetooth speaker with the plugin on the players that continue to hang.
If I’ll get a continuos playing it will be a final confirmation that the problem is the standard audio.
Many thanks
Regards
Marcello