Hello Rafael,
Thanks for the advice. My kernel ist not the latest, it is *Linux Raspi1
3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux*
I can do a firmware update but want to make a backup first.
My streaming project is for transferring amateur radio RF signals
received in my garden (low man made noise level) via a 2.4 km distant
WLAN link. The WLAN link is permanent and the whole system is solar
powered 24/7. The Raspi is hanging on a tree in 15m above ground level
in a waterproof box... Thus i need some time before doing the next
firmware update...
_I'm still having problems with buffer overruns_ :-( While using a
mono-microphone input soundcard in the past, it was no problem to run
the stream over days at 48kS/s / 16bit, vorbis vbr q=1.0 and about 33%
CPU load on a *Raspi B+* The data rate was about 215 kbps.
Then i took a soundcard with stereo inputs and run 48kS/s, 16 bit,
stereo, vbr, q=1.0. The CPU load is about 68% and the data rate ist
about 480 kbps.
With darkice-1.0 i got a loss of the stream data after about 1 hour. The
process was still running on the Raspi and the Client software
(SpectrumLab) was still connected to the stream. It showed a data rate
of 32 kbps and there was no sound any more. During that state, the CPU
load was about the same.
Now with darkice-1.2, this stream loss or sound loss happens even more
often :-( and i'm getting several "buffer overrun" messages. Both
versions were running at
*bufferSecs = 3 # size of internal slip buffer, in seconds
reconnect = yes # reconnect to the server(s) if disconnected
realtime = yes # run the encoder with POSIX realtime priority
rtprio = 98 # scheduling priority for the realtime threads
*- I'm using darkice-1.2 in combinatiom with mpd and icecast2.
- I cannot increase the slip buffer size because this would result in a
higher time delay (no problem for a web radio but a life RF streamig
does not allow a time delay of more than 2 sec).
- The maximum data rate over the long WLAN distance is sometimes in the
range of less than 1000 kbps, so it could be that the WLAN channel usage
may be a bit higher (by other WLANs on the same channel), so the
possible data rate may fall, so this could be a reason for sporadic
glitches or a loss of the stream... But last night i reduced the quality
to from q=1.0 to q=0.8 which reduces the data rate to about 280kbps. But
this has no effect on the stability / availability of the stream.
- Ah and BTW, i'm often getting the message *Raspi1 kernel:
[69972.281083] sched: RT throttling activated* , well known i guess..
Now my questions:
- Is this a regular configuration problem that you know and do you have
further advice?
- Could it be a problem of the priority of other streaming components
(mpd, icecast2, etc...)?
- Why is the stram still running but "no sound"?
- Is there a way to check for the actual data rate of the stream so i
can write a shell script, asking "if date rate less than xyz, then
restart" ?
(- Occasional glitches are not so dramatic but at least i want to keep
the stream being available.)
- Do you really assume that a kernel update will have an effect on the
streams stability?
I hope my problem description is reasonable complete and someone has
more advice :-)
Regards, Stefan
Am 23.06.2015 15:48, schrieb Rafael Diniz:
I do suggest using kernel 4.0 or greater.
Best regards,
Rafael Diniz
