Dropouts with snapclient v0.23 and ALSA backend #774
Labels
Comments
|
From which device are the 0.23 logs? Raspberry Pi 1, 2, 3? What audio device was used? Onboard sound? What OS? (is Linux amadeus an OS?) You can also try to change the player parameters ( E.g. |
|
Hi badaix, thanks for your fast reply! First the answers to your questions: amadeus is the hostname of the player running snapclient. It's a All reported logs were created on that Raspberry Pi 3. My audio device is a HifiBerry DAC. Trying snapclient v.0.23 or v.0.22 with a smaller 'buffer_time' still produce dropouts: snapclient --logfilter *:debug --player alsa:buffer_time=50,fragments=2 -h cms I tested also snapclient v.0.21. This version is running fine, witout any dropouts. |
|
thanks, but I don't think that sticking to an older version is a solution to this problem. There are three parameters involved for alsa:
where
There is always one fragment rendered, while another fragment is filled with new data that will be rendered later. For smooth playback without dropouts you will need at least two fragments, which actually seems not enough, so 3 or 4 are recommended. Your issue seems to be that Snapclient requests 4 fragments and 80ms buffer time (and expects to get 20ms fragments, but that's left to alsa and the hardware): What you get is 250ms buffer and 2 fragments (= periods), 125ms each. The differences between Snapclient versions are:
A request is just a request and alsa will try to apply them or use values close to the configured ones. |
|
Using snapclient --logfilter *:debug --player alsa:buffer_time=120,fragments=4 -h cms |
|
Thanks for testing this. It seems that alsa is still applying the same settings, especially 2 fragments (periods): I've now changed d03a9ea the alsa player to set the period time instead of the buffer time, as it was done in v0.21, you can find a snapshot debian package in actions |
|
Dear Johannes, GREAT WORK! Running the pached version, I can't hear anymore dropouts and the log also don't show any hicups. pi@amadeus:~/downloads $ snapclient -v Written by Johannes M. Pohl. pi@amadeus:~ $ snapclient --logfilter *:debug -h cms --latency=3 --player=alsa |
|
Sounds good (literally) :) There is still a difference between v0.19 and v0.23.dev: the number next to the end is 125 vs 250. This number is the playout time [ms] for the currently requested audio chunk, which will be a multiple of the fragment size (in your case the fragment size seems to be fixed to 125ms ( v0.19: v0.23.dev: I want to accept your offer to test one more development version (in actions with the commit message Thanks in advance PS: the version number of this snapshot is set to 0.23.100 |
|
Ok, here we are ... pi@amadeus:~/downloads $ snapclient -v pi@amadeus:~/downloads $ snapclient -v |
|
Thanks :)
Sorry, what I meant is to run the 0.23.100 with Edit: the 0.23.100 log looks already as expected, the default is to use buffer_time 80 with 4 fragments, so Snapclient requests a fragment time of 20 (= 80 / 4) and gets 125 (the only fragment time supported by your DAC (or driver)), then Snapclient requests a buffer time "near to 80" and gets 250, because alsa decides to use at least two fragments (which is perfectly reasonable, one fragment will not work without audible drops). Now I'm still curious what you will get with FYI: The 0.23.100 heuristic is the same that the alsa tool |
|
First the good news, version 0.23.100 with parameter buffer_time=120,fragments=4 is running without any errors on player amadeus. Here are the logs from client amadeus (Raspberry Pi 3 with audio device driver sndrpihifiberry ) and client ludwig a Raspberry Pi Zero with the same audio device driver as client amadeus. pi@amadeus:~/downloads $ snapclient --user snapclient:snapclient --logfilter *:debug -h cms --player alsa:buffer_time=120,fragments=4 Now, the test on the Raspberry Pi Zero pi@ludwig:~ $ aplay -l If I switch back to snapclient v.0.19, everything is ok: |
|
Thanks again for testing. I think the problem with the pi zero is that you didn't configure One last favor: I've built the 0.23.101 |
|
Ok, I tested snapclient v.0.23.101 on player amadeus (RPI 3) as well as on player ludwig (RPI Zero). Using this version , both clients are playing fine, without any dropouts. pi@amadeus:~/downloads $ snapclient -v pi@ludwig:~/downloads $ snapclient -v To complete the test results. here is the log from testing ludwig with the previous patch v.0.23.100 and pi@ludwig:~/downloads $ snapclient -v |
|
Thanks :) |
|
Might be solved now with the commit |
|
Yes, it seems that the problem is solved now! Thanks a lot for the effort you put into the development and maintenance of snapcast. |
|
Great, thanks again for testing! |
|
Hi Guys I've been watching this thread keenly, as I've been having the same dropout issues on a Pi Zero with ALSA and an adafruit voice bonnet. The hardware works as expected playing local mp3's using the mpg123 client. This is my first exposure to snapcast so I've been using the latest 0.23 release of the server and client. The win32 client worked out of the box, but I had audio dropouts with the armhf client. I've just tested with the .102 armhf client from the "Disable ccache in CI for debian packages" build, and if I run the client on its own without any command line parameters, then I sill get regular dropouts, but if I use the command line parameter "--player alsa:buffer_time=360,fragments=2" then everything seems fine. Using buffer_time of 120 and 240 still gives dropouts so I kept increasing until I got a successful outcome. So, a couple of questions if I may...
Kind regards |
|
|
Hi @badaix Thanks for the clarification on how the SNAPCLIENT_OPTS works. I'll download those other builds, do some more testing upload the logs for you |
|
The log output of the most recent release might be enough to get an idea of what's happening |
|
Hi @badaix Thanks for looking into this. Attached is the output from the "Disable ccache in CI for debian packages" build without passing any command line parameters Kind regards |
|
I think I may be having a similar problem when running on my pi0. I've tried restarting the client with Here are the logs I was noticing from before if they can be any help: $ uname -a
Linux snapclient-pi0 5.4.83+ #1379 Mon Dec 14 13:06:05 GMT 2020 armv6l GNU/Linux$ snapclient -v
snapclient v0.23.0$ snapclient -l
0: null
Discard all samples (playback) or generate zero samples (capture)
1: raspiaudio
2: default
3: sysdefault:CARD=sndrpihifiberry
snd_rpi_hifiberry_dac, HifiBerry DAC HiFi pcm5102a-hifi-0
Default Audio Device
4: dmix:CARD=sndrpihifiberry,DEV=0
snd_rpi_hifiberry_dac, HifiBerry DAC HiFi pcm5102a-hifi-0
Direct sample mixing device
5: dsnoop:CARD=sndrpihifiberry,DEV=0
snd_rpi_hifiberry_dac, HifiBerry DAC HiFi pcm5102a-hifi-0
Direct sample snooping device
6: hw:CARD=sndrpihifiberry,DEV=0
snd_rpi_hifiberry_dac, HifiBerry DAC HiFi pcm5102a-hifi-0
Direct hardware device without any conversions
7: plughw:CARD=sndrpihifiberry,DEV=0
snd_rpi_hifiberry_dac, HifiBerry DAC HiFi pcm5102a-hifi-0
Hardware device with all software conversions |
|
Here are the missing logs from my testing of v.0.23.102 ...
pi@amadeus:~ $ snapclient -v pi@amadeus:~ $ snapclient --user snapclient:snapclient -h cms --logfilter *:debug pi@amadeus:~ $ snapclient --user snapclient:snapclient -h cms --logfilter *:debug --player alsa:buffer_time=120,fragments=6
pi@ludwig:~ $ snapclient -v pi@ludwig:~ $ snapclient --user snapclient:snapclient -h cms --logfilter *:debug pi@ludwig:~ $ snapclient --user snapclient:snapclient -h cms --logfilter *:debug --player alsa:buffer_time=120,fragments=6 |
|
@mrdago thanks, the "125" is back (which used to be 250 in interim versions), that's good 😃 : |
|
@TotalSpaceshipguy Your logs are looking similar to mrdrago's logs. Snapclient requests a total buffer of 120ms, splitted into four fragments, but your device/driver can only handle buffer fragments of 125ms. Trying to get close to the requested buffer time, Alsa decides to use two fragments, summing up to a total buffer of 250ms (I guess Alsa would not use less fragments, because one is not enough for smooth playback (there is always one fragment played out, while other's are being filled with new "to-be-played" data)). So, make your self prepared for some test version(s) 😉 |
|
@TotalSpaceshipguy Please try the version in actions with the commit message |
|
I have been using v0.22 without problem since December until now. I have seen v0.23 earlier today. So, I built it from new in Raspbian Linux moode 5.4.77-v7+ #1371. My Raspberry Pi model 3B+ 1GB RAM. I have modified moOde Player's codes to add GUI to enable Snapserver, Snapclient, Airplay, and Spotify. I have left the amplifier in idle for a few hours. Then, I played music again without experiencing "drop out". Here is the version I am using now: snapserver v0.23.0. I have both snapserver and snapclient running on the same machine: /usr/bin/snapclient --logsink=system -s sndrpihifiberry , /usr/bin/snapserver --logging.sink=system --server.datadir=/var/lib/snapserver , /usr/local/bin/librespot --name Spotify Library --bitrate 320 --backend pipe --initial-volume 100 --verbose , /usr/local/bin/shairport-sync --name="Airplay Library" --output=stdout --use-stderr --get-coverart --metadata-pipename=/tmp/shairme . I have not tried separate client server yet. But, I will try tomorrow. Product used is Soundberry Audio's Raspberry Pi + headphone amplifier HPA02A. I will try client-server tomorrow with PA90A which has class-D output. |
|
Thanks @badaix for this incredible project and the fix -- I believe I was seeing the same exact issue, and with the latest |
|
Thank you so much @badaix for your awesome project and the fix! log extract with default config 2021-02-09 21-49-36.114 [Debug] (Stats) Chunk: 0 0 1 0 179 250 0 |
|
Client log looks good. Maybe you have resync events on the server |
|
I'm seeing similar issues, but my debug output is kinda different This is running on a rpi4 with a arm64 build that i did myself. I've built off of the develop branch at commit 2a1fde8 server is an rpi4 running 0.23 tag on arm64 i should also note that, this DID work at one point. i recently moved my audio server and that's when i noticed the problem. snapclient -s default:CARD=audioinjectorpi --logfilter *:debug |
|
I've managed to get it to play "audio" with a very very high fragment:
anything lower than this, and it's a mess. Reading through this issue more closely, i think this means my output device is really bad. I've always had trouble with keeping this device in sync with the others, and i think this is just time to replace it. |
|
try with |
|
@badaix With sample format i'm still needing to have a lot of fragments to get anything passable. here's the output of that with only sample format: |
|
after moving one of my "working" setups to arm64 and recompiling at the 0.23 tag or the current tip of develop, i've got the same issues on it as well. i have to use a very high fragment in both cases. i wonder if it's an arm64 issue? |
|
@sebirdman what OS are you running one? What is an audioinjectorpi? Can you try if it's working with a physical audio device? Is |
|
@badaix I'm running ubuntu 20.04 and audioinjectorpi is this device: http://www.audioinjector.net/rpi-hat I may be able to try with the headphones plug on the rpi later today, will try to get that for you Edit: Linux recordplayer 5.4.0-1028-raspi #31-Ubuntu SMP PREEMPT Wed Jan 20 11:30:45 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux without specifying the device, the log output looks correct. if i just try to raise the buffer time, i just get messages like: |
|
The "requested chunk duration" should be some multiple of the fragment time (125ms), but in least cases the full buffer time (500ms). Maybe the audioinjectorpi driver doesn't reliably work on 64 bit arm. |
very well could be, this audio hat doesn't seem to have much support now and honestly it's amazing that it works at all I've swapped to the pulse backend, and amazingly its all working quite well so far. even with the default buffer settings. |
|
Hi Badaix, Hi everyone, First of all thank you so much for snapcast which is running 24/7 ! My whole family gives you a huge hug, specially my 3 year old son who wants to listen to his lullabies all the time in the kitchen and livingroom with perfect sync of course ! I'm following this discussion with great interest as I'm experiencing also some hiccups/stuttering with a new system I'm trying to setup for my kids in their room. Everything went flawless. Amazing ! 🥇 However, when using Hifiberry miniamp, everything works well until I used snapcast (snapserver and snapclient on the same rpi0), meaning that there was no hiccups/stutter when audio output of Mopidy was directed to the Hifiberry miniamp. However when using snapclient, hiccups are appearing and quite a lot actually. I first though the issue was the SD card. But using other ones led to the same symptoms. Everything went flawless (with custom parameters of snapclient to select the correct device) ! 🥇 What ?!?! 😮 I'm kind of lost here now. Unfortunatly I'm not competent enough to understand how snapcast is configured through Volumio (besides the usual snapclient and server parameters). But I guess Volumio layer is doing something in the audio treatment that makes the hifiberry miniamp works with snapcast. I didn't save the logs of the system I'm trying to setup, but I will try to send them in the coming days. I just wanted to share my thoughts about this issue and the fact that it is properly working under Volumio. Which I find weird. 😲 PS: I could also stick to Volumio but Volumio is under Python 2.7 and based on Jessie. I'd rather at least start this new project with the latest release i.e. Buster, python 3.7, Pillow 8.1.0 etc. Cheers |
|
The volumio plugin seems to contain the ancient v0.15.0 Snapcast. |
I will post my logs, config and setup. I probably should have wait to get them before posting. Sorry about that. |
|
Good evening @badaix , As promised here are all the infos about my setup. /boot/config.txt aplay -l /etc/asound.conf snapclient --version snapserver --version snapclient -l /etc/default/snapserver /etc/default/snapclient /etc/mopidy.mopidy.conf Snapserver log Snapclient log I hope it helps. Best regards, |
|
There is no |
|
@sebirdman PulseAudio is using alsa as backend to play audio. Did I understand right that you don't have any problems with a 32bit OS and dropouts on 64bit?
and of
for both cases, once while playing audio with alsa and once with pulse? |
Thanks for the explanation. If I understand well the stream is fully configured in /etc/snapserver.conf and the /etc/default/snapserver is only for extra config I guess ?
I changed the configuration to 44100 Hz in Mopidy and Snapserver.conf like you suggested but it didn't solve the issue. (I also removed wavenc as mentionned in #592 and according to https://github.com/badaix/snapcast/blob/master/doc/player_setup.md) Config and logs below : mopidy.conf snapserver.conf I don't understand why snapserver switches states. snapserver log Maybe the issue comes from Mopidy. I will investigate further. Let me know if you want me to move posts to somewhere else. Thanks for your help. |
|
It's actually recommended to use the alsa loopback device instead of the snapfifo file, I read in other issues that mopdiy (gstreamer) playback is not really stable when using the filesink. |
|
Hi, I have also dropouts and I am not able to solve it. My combination, that works better is 0.22 on server and 0.24 on clients. There I have some dropouts only very sproradic (one over 10 Minutes). With 0.22 on client it is getting worse over time. I have tried several value combinations of What I didn't test yet, is to replace filesink whith alsa loopback. Linux sound is not my favorite piece of software. MPD is sending music to snapcast via filesink here |
|
Hi, I investigated the issue further and in my case drop outs were coming from the upstream (before the pipe). I ended up with a restart from scratch with my rpi 3B+ instead of rpi 0 W, with a different SD card (smaller 16GB instead of 32GB) and configuring alsa loopback instead of filesink. CONCLUSION : It worked perfectly with snapcast version 0.23 with default configuration of buffer/fragments/bitrate. I'm now thinking that the issue was probably the SD card, filesink or rpi 0 W or a combination of those. For those interested you may find my config files below : System : RPI 3B+ with Hifiberry miniamp /etc/modules /etc/asound.conf /boot/config.txt /etc/mopidy/mopidy.conf /etc/default/snapclient /etc/snapserver.conf Hope it helps and thank you @badaix for your help and suggestions 👍 |
|
To anybody reading this: please also consider WiFi-related issues such as network congestion. In my case I had to reduce the number of connected clients because all my WiFi clients - including laptops - on the 2.4 GHz band in my place are suffering systemic latency drops every 30 seconds or so (maybe it's a router issue? I don't know, I don't have other routers to try). That causes problems to snapcast because the flow of packets must be steady. To make it work perfectly I have to increase snapcast latency to 2-3 seconds. |
|
There are many reasons for stuttering audio
What you can do:
|
|
Thanks @badaix. You should really write a wiki page or something with all this stuff collected :-) It's been really hard gathering all the information around. I did my research and practically tried all of the above. In my case it's clearly a wireless issue. The problem is very clear and reproducible (traffic analysis, ping tests). I tried disabling some stuff polluting the 2.4 GHz band and I had some improvement, but then I had to enable them back, so... I guess the real solution would be to switch the RPi ZW to 5 GHz but I need an external WiFi controller. I'll think about it. |
marklarr
added a commit
to marklarr/balena-sound
that referenced
this issue
May 24, 2021
… fixes stuttering
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm running snapserver on a small Intel server and snapclient on various Raspberry PI (2,3,4). Last weekend I started to upgrade the server and clients from snapcast v.0.19. to snapcast v.0.23. On the server I'm using pulse audio with the following snapserver configuration: **source = pipe:///tmp/snapfifo?name=snapcast&mode=read
The linux clients use the alsa audio interface and don't have pulse installed. I can't remember any problem with snapclient v.0.19, but with snapclient v.0.23 I was faced with terrible dropouts (see logs).
Downgrading the client to v.0.19 fixed the issue. Unfortunately I'm not deep enough in technical details to provide more information. Here is my OS configuration:
Server: Linux cms 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64 GNU/Linux
--- snapserver & snapclient v.0.23 => no issues
Client: Linux amadeus 5.4.83-v7+ #1379 SMP Mon Dec 14 13:08:57 GMT 2020 armv7l GNU/Linux
--- snapclient v.0.23 (alsa, no pulse installed) => dropouts, downgrade to snapclient v.0.19 fixed the problem
snapclient v0.23.0: DROPOUTS
snapclient v0.19.0
The text was updated successfully, but these errors were encountered: