>
>- most people think udp is evil ;)
>
UDP is a far better match for audio transmission than TCP. The issue comes
does two the difference between the two protocols when it comes to packet
loss. Assuming the loss was due to CRC errors or drops under congestion then
TCP will recover the lost data itself. UDP will not as it has no concept of
transmission control.
The ability of TCP to recover this loss points people in the direction of
preferring the protocol, but this is not the case with audio. If there is
loss of framing with audio transmission over IP then a better recovery is to
accept the loss and resync the data streams. This is in effect what Jack
does with audio overruns in soft mode. Relying on TCP to handle the recovery
means that you have to wait for the resync, and that works very, very badly
with TCP, you are likely to go into a slow start and will have the available
bandwidth throttled down to the point where very little audio will get
through. The only way for a TCP based audio application to deal with this
effect (Van Jacobsen algorithm) is to have adaptive resampling rates where
the sampling rate over the network is a function of the bandwidth available.
Since the back off algorithm in TCP effectively throttles your available
bandwidth then your netjack will have to adapt its resampling rates
accordingly, or lose sync completely. Now with TCP, the protocol will
attempt to recover all the data you sent, rather than accept the overrun and
continue.
The use of UDP will allow you programme to define its own sampling rates,
define its own UDP transmission rates, the application (netjack) will then
just have to deal with drop outs, zero filling being one option for example.
>
>- it looks like i am the only one messing with BIG (16k) udp packets in
> low latency situations under high SCHED_FIFO load.
>
If you are looking to put this application over the internet, then these
large (or rather 'jumbo') frames are a no-go. The internet does not support
large frames, 1480 being the largest generally accepted payload. If you send
a jumbo frame then the nearest router to you transmitter will have to
fragment the packet from 1x16k down to about 12x1480 byte packets. This
negates any hardware based routing as this generally takes place in software
running under the router OS. In short you will add a lot of overhead to your
application: it is very likely that 12 frames of 1480 bytes would arrive
faster than one 16K frame that has been fragmented since you will not have
incurred the overhead on the router to fragment the jumbo. There is
additional downside in that the loss of a single fragmented frame will
result in the loss of the whole jumbo. The loss of a single 'small' frame
will be that single loss only as IP is no longer responsible for reassembly
of the fragments at the destination - your application is given that
responsability.
Nick.
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Received on Mon Apr 17 16:15:09 2006
This archive was generated by hypermail 2.1.8 : Mon Apr 17 2006 - 16:15:09 EEST