Hi all,
Let me report about the reason why i got permanent stream data losses
and buffer overruns:
The Raspi is using a 8 GB SD card. On my Raspi, there is not so much
software installed, just the normal suggested stuff. Anyway the card
usage is 58 %. There are 2.3 GB left now.
In my initial darkice.cfg file i didn't disable the line containing the
dump file.
Now it is!
*#localDumpFile = dump.ogg # local dump file*
Previously, darkice was recording to that file, at times (don't know
when and why). This file became very large, more than 1 GB.
And this led to:
*pi@Raspi1 ~ $ df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 5.6G 5.6G 0 100% /
/dev/root 5.6G 5.6G 0 100% /
*
No space left! And this must have led to the "semi-crash", i.e. the data
loss, while the process was still active and the stream contained no
information and showed something near 38 kbps.
Since i disabled that line (and deleted the GB file), _*darkice is
running stable, **not a single buffer overrun since 2 days now*_!!
You can see some spectrograms beeing generated from the remote stream
at: http://www.iup.uni-heidelberg.de/schaefer_vlf/DK7FC_remote_Grabber.html
Regards, Stefan
Am 24.06.2015 14:03, schrieb Stefan Schäfer:
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
