bryangrim / darkice

Automatically exported from code.google.com/p/darkice
0 stars 0 forks source link

Bugs in remote streaming (thorough examination) #103

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Remote streaming server
2. and network packet loss or a short (less than a second) network outage.

What is the expected output? What do you see instead?
If only a small number of packets is lost, Darkice should continue without any 
noticeable problems, but instead, after a single lost packet, it reconnects.

What version of the product are you using? On what operating system?
Darkice 1.2 on any linux distribution.

I examined the code and it seems that using a remote server has not been a goal 
in designing tcpSocket class or the classes using it either directly or 
indirectly. There is an assumption everywhere that one can always write to 
underlying sinks, and if not, then a reconnection is necessary, but this is not 
the case.

The code should be revised with a remote server in mind. Let me state the main 
problem points regarding this issue:
1. TCP socket connection is blocking, which results in a dsp source buffer 
overrun when a short network outage forces send-function to wait.
2. Encoders write to underlying sink without first testing if one can actually 
write there.
3. BufferedSink passes exceptions from encoders to MultiThreadedConnector even 
if it has space in its buffer.

Original issue reported on code.google.com by kulon...@gmail.com on 20 Feb 2014 at 9:06

GoogleCodeExporter commented 8 years ago
I made a patch to fix both this issue and the issue 100 in r558. There are 
quite signifigant changes, so I hope people will test it and report here how it 
works in different configurations.

I moved BufferedSink from top of the encoders to top of the TcpSocket, so 
BufferedSink deals now with encoded audio instead of raw audio. Therefore, 
bufferSecs setting in the config file doesn't set an accurate length of the 
buffer any more, but instead it is an approximate lower bound of the buffer 
length.

Original comment by kulon...@gmail.com on 21 Feb 2014 at 1:11

Attachments:

GoogleCodeExporter commented 8 years ago
Jmarktur has helped me a lot testing the changes I made, and thanks to him, we 
found a couple more issues related to remote streaming. I will post a new patch 
addressing these new issues after we have tested it carefully.

Original comment by kulon...@gmail.com on 26 Feb 2014 at 7:20

GoogleCodeExporter commented 8 years ago
Patch applied in r559.
Thanks.

Original comment by rafael2k...@gmail.com on 26 Feb 2014 at 7:49