Re: [linux-audio-dev] It's time to vote (n. 1)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] It's time to vote (n. 1)
From: Joe Pfeiffer (pfeiffer_AT_cs.nmsu.edu)
Date: Fri May 25 2001 - 17:54:48 EEST


   Of course, you're right. Dropped packets are a problem. In TCP they get resent, so
   they can be out of order. In UDP, I think everything that arrives (*if* it ever
   arrives), arrives in order. Of course, that's part of the reason why TCP causes more
   overhead than UDP (the computer the data gets sent to, has to acknowledge having
   received the packets, and after some time, if there has been no acknowledgement,
   packets get resent etc.). But I think that it is not too bold a statement to say that
   in single segment LANs, you won't have dropped packets.

I think (weak statement here) that you're right about UDP packets
arriving in order, if at all, in a single-segment network. But I
wouldn't want to bet on it.

You can certainly have dropped packets in a single segment, if it's a
busy single segment, or even a slow receiver.

   I think that collision resolving is part of the ethernet (physical access layer), so
   UDP packets always get sent without collision _once_. When they get dropped by a router
   who is flooded eg., then the packet dissapears of course... but packets don't dissapear
   because of collisions ...

Collision resolution is part of the physicalor data link layer (I
forget which); at any rate, you're right that it's handled in the
NIC. But at some point the NIC will decide a packet just isn't going
to make it, and gives up on trying to send it. I don't know if the
sender gets notified about this happening (though I would certainly hope so).

   Also note that even when some packets get dropped, you could introduce some redundancy
   into your stream. That has a cost though (less speed) and I don't know if it would be
   feasible.

What exactly is the goal of the sound-across-network? If you're
trying to do offline editing, the vital thing is to get every bit
across, and you want something resembling TCP. If you want real-time
response, you need to just use a fire-and-forget protocol like UDP,
and have the receiver interpolate if some data doesn't arrive in
time. There's already enough error correction built in that you can
pretty much take it for granted that if a packet arrives it's going to
be right, so about the only way I can see to introduce redundancy
would be to send redundant packets, which seems like a real bandwidth
hog.

   I think the best way is to use a LAN, which doesn't drop packets ;). I even think that
   I would even buy seperate dedicated NICs :) (then of course, you are sure you have your
   bandwith four your audio and you don't have to fool with QoS stuff).

I think somebody who was serious would do that. But most users would
be hobbiests like me...

> Even if it does turn out that packets always arrive in order in a
> single network segment, it would be a bad mistake to assume this in a
> protocol.

   Hm, I might agree.
   Of course, you could build the 'single network segment restriction' into the protocol ?

I estimate 48 hours between initial release and first bug report about
not being able to work between the CS and Music departments :)

Hmmm... while packets can arrive out of order, I would guess that
they rarely do under any reasonable circumstances. Maybe something
like a variable-length incoming packet buffer to stuff the packets
into as they arrive; if packets don't arrive in time to be played the
receiver interpolates, if late packets start arriving the system
introduces a latency to reduce their effect? (I did follow the
earlier discussion about maximum allowable latencies, and I realize
that this scheme would quickly get considered unacceptable if the
network got busy. But it would provide graceful degradation...).

-- 
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer
SWNMRSEF:  http://www.nmsu.edu/~scifair


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri May 25 2001 - 19:46:57 EEST