onResync spikes followed by muted audio

[abl]

Hi!

I'm noticing that, after a few hours, my audio stops.

I'm using arecord to pipe data from a line in; there's no obvious reason or signal...except that my onResync numbers jump from ~100ms to 10000ms.

If I kill and restart arecord everything works again - this produces a little gap in output but nothing major. According to arecord's VU meter it is continually sending audio.

The clients and server are just using default values - it's a wired network of 6 rPi2 clients with 1 rPi2 broadcaster.

Happy to provide any additional logs or details if it helps - I couldn't quite figure out what onResync means but a 100x spike seems relevant. :)

[badaix]

Hi,

the Snapclient wants to read every 20ms PCM data for 20ms from the pipe.
If it takes 30ms to read 20ms, the "onResync 10ms" message will be logged. So it looks like the PCM data is not written fast enough (i.e. in real time) into the pipe.
This will also happen when the PCM input signal is sampled at 44.1kHz and read by the Snapserver with 48kHz. Could this be the case?

[badaix]

Did you solve it, or maybe you have this problem: #16?

[1337sup3rh4x0r]

I am experiencing something similar. But I fear that my system is simply not powerful enough. I am running snapserver, snapclient and spotify-connect-web from fornoth on a Raspberry Pi 1 B. I notice that when I overclock, the stutters get less, but I can't get rid of them entirely.
Is anyone else running a pi 1 as server successfully or should I upgrade?

[badaix]

I suggest to upgrade ;)
The Snapserver is massively multi-threaded. So just the pure number of cores should help. Plus: each core of RPI2 and RPI3 is faster than the single RPI1 core.
You can also try without encoding: --codec pcm

[christf]

actually I think this is an issue.

I am seeing this on my system as well.

2018-12-21 22-17-31 [Info] onResync (default): 1382ms
2018-12-21 22-17-31 [Info] onStateChanged (default): 2
2018-12-21 22-17-43 [Info] onStateChanged (default): 1

It may be that the stream is late by 1382ms. At the same time my snapserver is running with 15s Buffer. That should be enough to compensate for 1.3s of data being late.