-
Notifications
You must be signed in to change notification settings - Fork 455
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dropouts on 1 of 2 almost identical rpi3 clients, none on any other clients #765
Comments
Here, another documented and very audible dropout, sapparently starting with some failed time sync request:
|
The line |
I think you were right 👍 . I had been grabbing a short black cable with RJ45 plugs from an older FritzBox router box lying around, that cable seemed to work but it must have been dodgy. After replacing it with a proper Ethernet cable from my colored short cables reserve bag I'm having in the basement anyway, the dropouts vanished, all good now! One more thing about Snapcast dependencies. The current development 0.23 snapclient didn't actually require me to pull in pulseaudio, the DietPi package manager (Debian Buster) only hinted at it as being recommended, but not mandatory, seems to be only a runtime dependency which only kicks in if the user configures such usage, it must be related to the new feature you're adding. Are you going to change that and link against it, according to you mentioning the build flag and make it a build time dependency? |
That's the advantage of WiFi cables: they don't break. Snapclient is linked dynamically against libpulse. I don't know what will happen when you start |
That seems to by runtime dynamic linking, so the program would not break right at startup as in loadtime dynamic linking, but only if the code path requiring the missing dynamic library is executed, which should only happen on specific request or configuration. That's ok, like it is now. If the user has no intention of using Meanwhile, my wired raspi3 client happily streamed for hours without dropping packets, so I will close this issue. Thanks again! |
I've gotten so much out of snapcast over the years, just wanted to share what I've found for dropouts and loud popping sounds with devices on wifi:
EDIT Just stop having snapclient manage the audio device directly. It has supported pulseaudio for quite a while now, so I updated my most frequent offender to use pulse instead of alsa. So far it's only exhibited the problem when pulse itself stops/starts. To get it working on a headless system:
|
Hi there, a Happy New Year!
After finally getting around to send back my then (#573) faulty, randomly loudly popping HifiBerry AMP2 and getting 2 brand new replacements and another new RPI3 just few days ago, I reactivated and updated my kitchen client and built an identical one for my home office room.
The only differences between them is that the kitchen one was updated to DietPi v6.34.3 with snapclient 0.22 and is hooked up to my LAN via WiFi and the all new office client has a brand new DietPi DietPi v6.34.3 installation which I tried to configure the same as the kitchen one and is hooked up to the LAN over Gigabit Ethernet. Initially it used the same snapclient version 0.22, now I'm also trying with the development version from Actions (0.23, unfortunately pulling in like 17 new dependencies, some of which are X11-related), but on this one, hooked over Ethernet, I'm getting annoying audio dropouts, sometimes like 2 within a minute, but mostly just several minutes apart, and it feels like the development version handles this a bit better, while on the kitchen client hooked up over WiFi I do not get them at all, even with 0.22. Also, I did not hear them on any other clients, like a debian x64 client running on the OMV NAS on which also the server runs, on Android / Snap.NET / Snap.Web or two CoreELEC / OdroidN2 clients hooked to TVs, of which all of them are connected via Gigabit LAN, except the Android Smartphones or a Tablet also.
It also makes no difference if the stream is LibreSpot or Mopidy. Because of LibreSpot, I configured my streams and audio outputs to 44100:16:2 sampling.
Log from the kitchen client, with everything ok:
Please observe the output about
PCM name
and alsoPCM state: PREPARED
. Other than that, the log goes on and on the same, all good:Log from the office client, with annoying dropouts from time to time:
Please observe the output about
PCM name
which now is more detailed, and instead ofPCM state: PREPARED
now it starts withFailed to start PCM: Broken pipe
, but that is only the startup, the dropouts follow in form ofXRUN while waiting for PCM: Broken pipe
, I even saw some where the snapclient had to reconnect:Does any of this make any sense? Should I also try connecting the client over WiFi (which I would actually want to avoid, even in the kitchen I'm about to finish mounting LAN outlets and switch to wired connection)?
Thank you,
Lucian
The text was updated successfully, but these errors were encountered: