Stefan,
one of the issues with the Pi and even the Pi2
is the USB buss handles everything
one thing i do not know is if the built in sound uses that buss as well
if it does then im betting that its all boils down to buss timing issues
causing things to go funny
and you use of the Pi as a remote radio server is something working on as
well
but im looking to use it as a solar powered spectrum server using a RTL_SDR
dongle
my next step is to try and get a wifi link running
the Pi and Pi2 are really challenged by these tasks
its looking like the Banana Pi and Banana Pi pro are going to be the way to
go here
as they have the wifi and ethernet as well as sound off the usb buss
as well as using a real EMMC storage drive instead of keeping the OS on the
usb buss
dont know if i helped
but maybe i gave you some things to think over
On Wed, Jun 24, 2015 at 9:03 AM, Stefan Schäfer <dk7fc@xxxxxx> wrote:
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
