cgutman
commented
10 years ago I'll decrease the DU_LIMIT values some because they are indeed a bit high.
The socket buffers though aren't acting the way you think they are (if I'm understanding your position). These aren't like audio buffers where all the data must make its way through them. They only fill during bursty times when the receive thread can't keep up, so they shouldn't have any effect on latency. The audio receive buffer could be lowered because audio tends to come in at a constant rate. I'm leaving the video receive buffer at 128KB because video tends to be very bursty. Frames are sent every several milliseconds, but some frames are very large (> 32KB) and I don't want data to be dropped in those situations.
irtimmer
Audio latency is currently a big problem in Limelight. The main cause lay in the excessive usage of buffers. While video can be played faster this isn't the case with audio. So if you wait long enough buffers will fill and the audio delay increase. At least on the Raspberry Pi the situation can be improved by removing the depacketizer thread. This thread can be merged with the receive thread because the OS already provides us with a packet buffer (RTP_RECV_BUFFER) so there is no need to maintain another one.
For Limelight-pi I decreased the size of the the other buffers as well in irtimmer@dc35277393a7548215b3838b719421251a2d3a16 to improve audio latency. It works perfectly over wired but I have no idea what the effect is on wireless connections. Maybe it would be nice to make these configurable so you can choose between less latency (for wired) or less artifacts (for wireless)