Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, 25 May 2001, Dan Hollis wrote: > On Fri, 25 May 2001, Steve Harris wrote: > > On Fri, May 25, 2001 at 03:07:08AM -0700, Dan Hollis wrote: > > > On Fri, 25 May 2001, Steve Harris wrote: > > > > On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote: > > > > > If you want to network low-latency audio I think you must find a network > > > > > solution with a reliable physical layer. > > > > Hear, hear. Ethernet just isn't designed to send low latency streams. > > > You can get 100% guaranteed latency and bandwidth with IP over ATM. > > I take it you haven't actually used ATM ;) Its a right pain in the ass. > > > That said, for single point-to-point streams it might be OK, I might > > borrow some of the ATM hardware when it gets checked and test it. There > > must be loads of businesses throwing it out around now, but its kinda > > large, you wouldn't really want it in your house. Would be OK in a studio. > > Er... ATM is a *protocol*, not a *physical link layer*. ATM usage is > growing not shrinking and I dont know any businesses "throwing it out". > With the extensive growth of broadband the last 2 years the amount of ATM > deployed has increased substantially and will continue to do so. /me starts to examine cable modem: IPSec TCP IP PPPoE <-- some unforunate ppl have this too! Ethernet ATM MPEG-TS Hum. ATM is quite important and all that (!) E&EO, Paul -- h: 0115 922 7162 w: 0115 953 1803
Re: [linux-audio-dev] It's time to vote (n. 1)
Actually, thinking about what I do in real life (to whatever extent a professor is involved with real life :) ) -- mobile robots -- it seems like there's a real need for a network protocol doing low latency, timestamped data over unreliable transports. Audio is an example application, so is robot swarms... -- 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
Re: [linux-audio-dev] It's time to vote (n. 1)
> What about using UDP instead of TCP/IP? I don't know a whole lot about > networking, but I do know that jMax uses UDP for interprocess > communication, and I know some people who have experimented with audio > over UDP for real-time work. jMax actually includes a UDP audio device. It's the audpdev package. It seems that the package in not in sync with the latest jMax version so I haven't tested it. It has both a sender and a receiver side so you can send an audio stream over UDP between two jMax machines. I think it was designed for minumum latency and each packet has a header so they can be kept in the right order. -- Peter Hanappe [EMAIL PROTECTED]
Re: [linux-audio-dev] It's time to vote (n. 1)
Ok, I think I might be confused, but packet resending I thought was deeper than TCP/IP, I thought it was apart of the ethernet protocol ( isn't it 802.3 or something like that ) And how it works is if there is a hardware detected collision the NIC will wait a random amount of time before resending. It will do this a few times and then after so many it will just quit. There are retransmits at different levels. As you point out, Ethernet is unreliable -- it will retransmit on collisions, and eventually maybe give up. TCP is a reliable protocol built on top of an unreliable data link layer; it guarantees that no matter what happens at lower levels, your packets will get through. So even if the Ethernet level gives up on a packet and drops it, the TCP level will ask the other end to send it again. Now what about full and half duplex, if you had just two systems in full duplex, what would happen there, you wouldn't have collisions for two machines I don't think. I expect you're right. -- 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
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, 25 May 2001, Steve Harris wrote: > Sorry, I thought ATM refered to the fibre too. There *are* a lot of people > throwing out ATM kit, because Newbridge's ATM customers have found > themselves with unsupported hardware, and the company that bought > Newbridge (can't remember who) is virtually paying us to replace it with > gigabit. gbe is the new commodity broadband, but you can still run ATM over it B) remember ethernet (10bt,100bt,1000bt) only specifies the physical layer and encoding method/framing. you can still run ipx/spx, ethertalk, ip, atm, or anything else you want over it. you could even write up an audio-over-ethernet packet type. still I suspect even the worst case latency for full duplex 100baseT is still sufficient for most audio. I mean, people are running "pro" audio gear on USB which has much worse latency and no real QOS guarantees either. of course you can use firewire if you need QOS guarantees for devices. > ATM is still used by telecoms people ofcourse, I was refering to its use > in computer networks. a number of tier1 IP providers use exclusively ATM... presumably they like it because of the QOS guarantees they can make with ATM. -Dan
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, May 25, 2001 at 10:51:24AM -0700, Dan Hollis wrote: > > That said, for single point-to-point streams it might be OK, I might > > borrow some of the ATM hardware when it gets checked and test it. There > > must be loads of businesses throwing it out around now, but its kinda > > large, you wouldn't really want it in your house. Would be OK in a studio. > > Er... ATM is a *protocol*, not a *physical link layer*. ATM usage is > growing not shrinking and I dont know any businesses "throwing it out". > With the extensive growth of broadband the last 2 years the amount of ATM > deployed has increased substantially and will continue to do so. Sorry, I thought ATM refered to the fibre too. There *are* a lot of people throwing out ATM kit, because Newbridge's ATM customers have found themselves with unsupported hardware, and the company that bought Newbridge (can't remember who) is virtually paying us to replace it with gigabit. ATM is still used by telecoms people ofcourse, I was refering to its use in computer networks. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, 25 May 2001, Steve Harris wrote: > On Fri, May 25, 2001 at 03:07:08AM -0700, Dan Hollis wrote: > > On Fri, 25 May 2001, Steve Harris wrote: > > > On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote: > > > > If you want to network low-latency audio I think you must find a network > > > > solution with a reliable physical layer. > > > Hear, hear. Ethernet just isn't designed to send low latency streams. > > You can get 100% guaranteed latency and bandwidth with IP over ATM. > I take it you haven't actually used ATM ;) Its a right pain in the ass. Actually I do use ATM. It's more a pain in the ass than straight ethernet, sure. > Our system suffers from chronic problems when using large numbers of > tunnels (a common situation), and the hardware is rubbish. Plus no-one > supports it anymore. Were having to strip out all our ATM kit and replace > it with gigabit. Sounds like a fault with the specific vendor you purchased from. One sucky vendor can't condemn ATM technology as a whole -- that's like saying ethernet sucks because 3com made sucky ISA NICs back in late 1980's. > That said, for single point-to-point streams it might be OK, I might > borrow some of the ATM hardware when it gets checked and test it. There > must be loads of businesses throwing it out around now, but its kinda > large, you wouldn't really want it in your house. Would be OK in a studio. Er... ATM is a *protocol*, not a *physical link layer*. ATM usage is growing not shrinking and I dont know any businesses "throwing it out". With the extensive growth of broadband the last 2 years the amount of ATM deployed has increased substantially and will continue to do so. -Dan
Re: [linux-audio-dev] It's time to vote (n. 1)
>[cut] >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...). > I agree ! I think the interpolating option would do nice (building in redundancy at samplelevel, could halve your samplerate, if you would introduce each sample twide eg.) When a packet is lost, you just interpolate it. In a month or so, I will have more time to play with it. Keep those ideas coming :) Regards Vincent
Re: [linux-audio-dev] It's time to vote (n. 1)
Ok, I think I might be confused, but packet resending I thought was deeper than TCP/IP, I thought it was apart of the ethernet protocol ( isn't it 802.3 or something like that ) And how it works is if there is a hardware detected collision the NIC will wait a random amount of time before resending. It will do this a few times and then after so many it will just quit. Now what about full and half duplex, if you had just two systems in full duplex, what would happen there, you wouldn't have collisions for two machines I don't think. Rick On Fri, 25 May 2001, Joe Pfeiffer wrote: > >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 > ++---+ | T a l i t y | +--+ | ++ ++-+| | | Richard Burnett |+-+| | | Senior Design Engineer +---+ ++ | | [EMAIL PROTECTED] | | | |
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, 25 May 2001, Joe Pfeiffer wrote: >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). Don't forget full duplex ethernet, where collisions simply do not exist... -Dan
Re: [linux-audio-dev] It's time to vote (n. 1)
Hear, hear. Ethernet just isn't designed to send low latency streams. Agree completely. But a project with a ``you must use Myrinet'' requirement isn't going to see much use. Better to build a protocol that will work really, really well with a reliable physical layer, and will degrade gracefully otherwise. -- 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
Re: [linux-audio-dev] It's time to vote (n. 1)
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
Re: Network audio, was Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, May 25, 2001 at 09:04:06AM -0400, rob wrote: > > http://oss.sgi.com/projects/stp/ > > they apparently use irix and gigE to get < 10us latency. (although it > is unclear what that number really means). Isn't that <10us latency over GSN? I couldn't see any latency figures for gig ethernet. BTW you can now get gigabit NICs for under UKP150 (about $250). - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, May 25, 2001 at 03:07:08AM -0700, Dan Hollis wrote: > On Fri, 25 May 2001, Steve Harris wrote: > > On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote: > > > If you want to network low-latency audio I think you must find a network > > > solution with a reliable physical layer. > > Hear, hear. Ethernet just isn't designed to send low latency streams. > > You can get 100% guaranteed latency and bandwidth with IP over ATM. I take it you haven't actually used ATM ;) Its a right pain in the ass. Our system suffers from chronic problems when using large numbers of tunnels (a common situation), and the hardware is rubbish. Plus no-one supports it anymore. Were having to strip out all our ATM kit and replace it with gigabit. That said, for single point-to-point streams it might be OK, I might borrow some of the ATM hardware when it gets checked and test it. There must be loads of businesses throwing it out around now, but its kinda large, you wouldn't really want it in your house. Would be OK in a studio. - Steve
Network audio, was Re: [linux-audio-dev] It's time to vote (n. 1)
recently i added another stack that did streamed stuff over ethernet for
this sort of thing. it seems to be workable. i also found this which
seemed promising:
http://oss.sgi.com/projects/stp/
they apparently use irix and gigE to get < 10us latency. (although it
is unclear what that number really means).
rob
---
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, 25 May 2001, Steve Harris wrote: > On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote: > > If you want to network low-latency audio I think you must find a network > > solution with a reliable physical layer. > Hear, hear. Ethernet just isn't designed to send low latency streams. You can get 100% guaranteed latency and bandwidth with IP over ATM. -Dan
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, May 25, 2001 at 09:03:53AM -0700, Vincent Touquet wrote: > 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. Sropped packets aren't an issue. On the kind of private, switchless network that you would have to use, a sropped packed would represent something severly wrong (broken hardware probably). The big problem, is that for whatever reason it can take >70ms for a packet to arrive, I can't think why it might take that long, but that is totally useless. Even the minimum time of 1ms is much too long. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
On Thu, May 24, 2001 at 01:03:51PM -0400, David G Matthews wrote: > What about using UDP instead of TCP/IP? I don't know a whole lot about > networking, but I do know that jMax uses UDP for interprocess > communication, and I know some people who have experimented with audio > over UDP for real-time work. AFAIK it's a little less reliable than > TCP/IP, but gives lower latencies. I *was* using UDP. TCP is much too slow. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
Vincent Touquet wrote: > Joe Pfeiffer wrote: > >>Hm, but the packets get sent in order, don't they ? >>So when there is a collision, the ethernet card waits to resend the > packet for >>which a collision happened, for some random time (exponentially increasing in >>case of another collision). But that cannot mean, that a packet that is after >>this packet in the queue, gets sent before this very packet is > succesfully sent, >>or is it ? >> >>Please explain more if I'm wrong. >> >> That corresponds to my understanding, though I could easily be wrong. >> I think the scenario I suggested -- packets could get out of order due >> to a dropped packet -- is possible, though. > > 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 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 ... > > 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. > > 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 don't think it's as simple as this. IP over ethernet (or elsewhere AFAIK) is fundamentally (by design) an "unreliable physical layer" protocol (which IMHO makes it unsuitable for low latency audio - although totally satisfactory for streaming). You will be back to the flame war about "how much low latency, and for what percentage of the time, must we guarantee" in a few mails time ;-))) It will work some of the time of course - but it will *never* be guaranteed. The drivers & network stack are perfectly at liberty to drop packet fragments that have been successfully received - for example, if there are no mbufs available. I have seen network stacks (not looked at the linux ones, I admit) that regularly do this. If you want to network low-latency audio I think you must find a network solution with a reliable physical layer. my 0.02 euro ;-) Iain.
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote: > The drivers & network stack are perfectly at liberty to drop packet > fragments that have been successfully received - for example, if there are > no mbufs available. I have seen network stacks (not looked at the linux > ones, I admit) that regularly do this. > > If you want to network low-latency audio I think you must find a network > solution with a reliable physical layer. Hear, hear. Ethernet just isn't designed to send low latency streams. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
On Fri, May 25, 2001 at 09:29:37AM +0200, Adriaan Pelzer wrote: > Sounds good... > > Only danger with UDP is when you have a bottleneck somewhere (receiving side > slower than sending side) you might drop packets. > Don't think it will be a problem with audio though... > > I've played with the libnet libraries (allow you to build raw packets) but I > think what we need here is libpcap. > > I'll check it out some time. (With both it's actually possible to write a > protocol on UDP doing the throttling but then we're heading TCP way) Throtling isn't an issue cos were dealing with small ammounts of data here. If the machine can't keep up with the ethernet card then it can't do the DSP work either. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
On Thu, May 24, 2001 at 04:52:26PM -0400, Taybin Rutkin wrote: > On Thu, 24 May 2001, Darwin Marcus Johnson wrote: > > > > Collisions. The packets back off (exponentially I think) so they can get > > > shuffled easily. > > > > > > There is more going on over ethernet than you think. > > > > > could this be avoided using two interfaces, and no hub? > > It seems to me that the problem is that UDP makes absolutly no promise > about the order the packets come in. So even with a certain hardware > setup that maintains the packet order (if such a thing is even possible), > there would still need to be code to handle the out of order situation or > it would be incorrect. And even if the packets were in order 99% of the > time, the 1% would still have to be handled. So it's not a matter of > removing the traffic from the link. That is true, but I never got round to putting the orer handling code in my benchmark code (just left an exit(1) in there) and it never got called, in quarter of a million test packets. I was being easy on the network, but even so. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
Sounds good... Only danger with UDP is when you have a bottleneck somewhere (receiving side slower than sending side) you might drop packets. Don't think it will be a problem with audio though... I've played with the libnet libraries (allow you to build raw packets) but I think what we need here is libpcap. I'll check it out some time. (With both it's actually possible to write a protocol on UDP doing the throttling but then we're heading TCP way) Regards, Adriaan Pelzer On 25-May-01 Vincent Touquet wrote: > The protocol they use in Disneyland is a protocol over ethernet developed by > Peak Audio (TM). > Homepage: http://www.peakaudio.com/CobraNet > Some place where you can hear their stuff: > http://www.peakaudio.com/CobraNet/Installations > > Note that indeed using TCP on a local LAN is an overkill for this stuff. UDP > is > good enough (packets don't get dropped on your local LAN, unless you have a > very busy network, or flakey hardware). > > We could test audio over UDP using netcat (there are certainly also netcat > sources and binaries for Solaris ;-) !!! > > You can netcat a raw audio file to a port on another host. > See http://www.l0pht.com/~weld/netcat/readme.html > See also http://www.l0pht.com/~weld/netcat/readment.txt for more example > usage > Type something like > nc -u -n other_computer 3000 < soundfile > on the computer you are sending the audio from. [-u specifies transfer over > UDP] > > On other_computer, you can make netcat listen on that port and spawn a > program > to receive the data which netcat receives on that port (and play the audio !) > nc -l -p 3000 -e receiving_prog > > Damnit, I just haven't got the time nor right computers here to test it :( > If anyone tries it, be sure to post it on the mailinglist (cursed areth thou > who not posteth on the ladlist ;-) if it works out or not (not sure if > receiving_prog could handle the received data etc. [what form that data is in > when it comes up at other_computer]) > > Note: if it doesn't work out perfectly, note that these protcols where not > specifically made for these applications. I'm sure we could come up with our > own audio-protocol over ethernet. I'm not saying it would be simple, but it > certainly is feasible. Nice, another project for the summer :P > > Regards > Vincent -- E-Mail: Adriaan Pelzer <[EMAIL PROTECTED]> Date: 25-May-01 Time: 09:24:16 This message was sent by XFMail --
Re: [linux-audio-dev] It's time to vote (n. 1)
Joe Pfeiffer wrote: >Hm, but the packets get sent in order, don't they ? >So when there is a collision, the ethernet card waits to resend the packet for >which a collision happened, for some random time (exponentially increasing in >case of another collision). But that cannot mean, that a packet that is after >this packet in the queue, gets sent before this very packet is succesfully sent, >or is it ? > >Please explain more if I'm wrong. > > That corresponds to my understanding, though I could easily be wrong. > I think the scenario I suggested -- packets could get out of order due > to a dropped packet -- is possible, though. 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 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 ... 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. 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). > 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 mean, if you can't get it working in another way of course. The more general the better. Regards Vincent
Re: [linux-audio-dev] It's time to vote (n. 1)
Hm, but the packets get sent in order, don't they ? So when there is a collision, the ethernet card waits to resend the packet for which a collision happened, for some random time (exponentially increasing in case of another collision). But that cannot mean, that a packet that is after this packet in the queue, gets sent before this very packet is succesfully sent, or is it ? Please explain more if I'm wrong. That corresponds to my understanding, though I could easily be wrong. I think the scenario I suggested -- packets could get out of order due to a dropped packet -- is possible, though. 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. -- 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
Re: [linux-audio-dev] It's time to vote (n. 1)
On Thu, 24 May 2001, Darwin Marcus Johnson wrote: > > Collisions. The packets back off (exponentially I think) so they can get > > shuffled easily. > > > > There is more going on over ethernet than you think. > > > could this be avoided using two interfaces, and no hub? It seems to me that the problem is that UDP makes absolutly no promise about the order the packets come in. So even with a certain hardware setup that maintains the packet order (if such a thing is even possible), there would still need to be code to handle the out of order situation or it would be incorrect. And even if the packets were in order 99% of the time, the 1% would still have to be handled. So it's not a matter of removing the traffic from the link. Taybin Rutkin
Re: [linux-audio-dev] It's time to vote (n. 1)
Steve Harris wrote: > > my understanding is that when packets get routed via different > > paths, they might become shuffled, but not on a static route. > > Collisions. The packets back off (exponentially I think) so they can get > shuffled easily. > There is more going on over ethernet than you think. > - Steve Hm, but the packets get sent in order, don't they ? So when there is a collision, the ethernet card waits to resend the packet for which a collision happened, for some random time (exponentially increasing in case of another collision). But that cannot mean, that a packet that is after this packet in the queue, gets sent before this very packet is succesfully sent, or is it ? Please explain more if I'm wrong. Regards Vincent
Re: [linux-audio-dev] It's time to vote (n. 1)
The protocol they use in Disneyland is a protocol over ethernet developed by Peak Audio (TM). Homepage: http://www.peakaudio.com/CobraNet Some place where you can hear their stuff: http://www.peakaudio.com/CobraNet/Installations Note that indeed using TCP on a local LAN is an overkill for this stuff. UDP is good enough (packets don't get dropped on your local LAN, unless you have a very busy network, or flakey hardware). We could test audio over UDP using netcat (there are certainly also netcat sources and binaries for Solaris ;-) !!! You can netcat a raw audio file to a port on another host. See http://www.l0pht.com/~weld/netcat/readme.html See also http://www.l0pht.com/~weld/netcat/readment.txt for more example usage Type something like nc -u -n other_computer 3000 < soundfile on the computer you are sending the audio from. [-u specifies transfer over UDP] On other_computer, you can make netcat listen on that port and spawn a program to receive the data which netcat receives on that port (and play the audio !) nc -l -p 3000 -e receiving_prog Damnit, I just haven't got the time nor right computers here to test it :( If anyone tries it, be sure to post it on the mailinglist (cursed areth thou who not posteth on the ladlist ;-) if it works out or not (not sure if receiving_prog could handle the received data etc. [what form that data is in when it comes up at other_computer]) Note: if it doesn't work out perfectly, note that these protcols where not specifically made for these applications. I'm sure we could come up with our own audio-protocol over ethernet. I'm not saying it would be simple, but it certainly is feasible. Nice, another project for the summer :P Regards Vincent
RE: [linux-audio-dev] It's time to vote (n. 1)
> -Original Message- > From: David G Matthews [mailto:[EMAIL PROTECTED]] > > What about using UDP instead of TCP/IP? I don't know a whole udp instead of tcp. both udp and tcp are part of tcp/ip (along with ip, icmp, ...) erik > lot about > networking, but I do know that jMax uses UDP for interprocess > communication, and I know some people who have experimented with audio > over UDP for real-time work. AFAIK it's a little less reliable than > TCP/IP, but gives lower latencies. > -dgm > > > On Thu, 24 May 2001, Steve Harris wrote: > > > On Thu, May 24, 2001 at 01:53:56PM +0200, Jörn Nettingsmeier wrote: > > > > Over ethernet it seem to be only the first packet that > is slow, probably > > > > depends on the make of switch though. Unswitched > private networks should > > > > be fine. But as Paul said these times are too slow to be useful. > > > > > > are there any obstacles in this setup i have overlooked ? > > > from my experience, ping latency is well below 500 usecs. > if that's > > > a measure for the actual audio latency, we'll be doing fine. > > > > Thats a measure of the minimum extra overhead, in practice > it will be a > > lot higher as you will have to pull the data from the > packet process it > > wrapper it back up again and send it back. > > > > Also remeber you have to reassemble the packets in the > right order as the > > ordering is not guaranteed. > > > > I might try some benchmarks if anyone is interested. I'm > guessing that you > > really need gigabit though. IP over SCSI or 1395 might be > an option, but > > that's far more exotic. > > > > - Steve > > >
Re: [linux-audio-dev] It's time to vote (n. 1)
Jorn Nettingsmeier Steve Harris wrote: > Also remeber you have to reassemble the packets in the right order as the > ordering is not guaranteed. forgive my ignorance wrt networks, but what can change the original order of packets in a point-to-point link ? my understanding is that when packets get routed via different paths, they might become shuffled, but not on a static route. A packet can be lost (maybe noise on the line, maybe the recipient missed an interrupt...), and the following packet get through. Then the lost packet gets retransmitted. -- 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
Re: [linux-audio-dev] It's time to vote (n. 1)
On Thursday 24 May 2001 13:21, Steve Harris wrote: > On Thu, May 24, 2001 at 06:03:30PM +0200, Jörn Nettingsmeier wrote: > > > Also remeber you have to reassemble the packets in the right order as > > > the ordering is not guaranteed. > > > > forgive my ignorance wrt networks, but what can change the original > > order of packets in a point-to-point link ? > > my understanding is that when packets get routed via different > > paths, they might become shuffled, but not on a static route. > > Collisions. The packets back off (exponentially I think) so they can get > shuffled easily. > > There is more going on over ethernet than you think. > > - Steve could this be avoided using two interfaces, and no hub? -Darwin
Re: [linux-audio-dev] It's time to vote (n. 1)
What about using UDP instead of TCP/IP? I don't know a whole lot about networking, but I do know that jMax uses UDP for interprocess communication, and I know some people who have experimented with audio over UDP for real-time work. AFAIK it's a little less reliable than TCP/IP, but gives lower latencies. -dgm On Thu, 24 May 2001, Steve Harris wrote: > On Thu, May 24, 2001 at 01:53:56PM +0200, Jörn Nettingsmeier wrote: > > > Over ethernet it seem to be only the first packet that is slow, probably > > > depends on the make of switch though. Unswitched private networks should > > > be fine. But as Paul said these times are too slow to be useful. > > > > are there any obstacles in this setup i have overlooked ? > > from my experience, ping latency is well below 500 usecs. if that's > > a measure for the actual audio latency, we'll be doing fine. > > Thats a measure of the minimum extra overhead, in practice it will be a > lot higher as you will have to pull the data from the packet process it > wrapper it back up again and send it back. > > Also remeber you have to reassemble the packets in the right order as the > ordering is not guaranteed. > > I might try some benchmarks if anyone is interested. I'm guessing that you > really need gigabit though. IP over SCSI or 1395 might be an option, but > that's far more exotic. > > - Steve >
Re: [linux-audio-dev] It's time to vote (n. 1)
On Thu, May 24, 2001 at 06:03:30PM +0200, Jörn Nettingsmeier wrote: > > Also remeber you have to reassemble the packets in the right order as the > > ordering is not guaranteed. > > forgive my ignorance wrt networks, but what can change the original > order of packets in a point-to-point link ? > my understanding is that when packets get routed via different > paths, they might become shuffled, but not on a static route. Collisions. The packets back off (exponentially I think) so they can get shuffled easily. There is more going on over ethernet than you think. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
Steve Harris wrote: > > On Thu, May 24, 2001 at 01:53:56PM +0200, Jörn Nettingsmeier wrote: > > > Over ethernet it seem to be only the first packet that is slow, probably > > > depends on the make of switch though. Unswitched private networks should > > > be fine. But as Paul said these times are too slow to be useful. > > > > are there any obstacles in this setup i have overlooked ? > > from my experience, ping latency is well below 500 usecs. if that's > > a measure for the actual audio latency, we'll be doing fine. > > Thats a measure of the minimum extra overhead, in practice it will be a > lot higher as you will have to pull the data from the packet process it > wrapper it back up again and send it back. > > Also remeber you have to reassemble the packets in the right order as the > ordering is not guaranteed. forgive my ignorance wrt networks, but what can change the original order of packets in a point-to-point link ? my understanding is that when packets get routed via different paths, they might become shuffled, but not on a static route. -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/
Re: [linux-audio-dev] It's time to vote (n. 1)
On Thu, May 24, 2001 at 08:22:43AM -0600, Joe Pfeiffer wrote: > (delurking momentarily) > > I also get round-trip latencies much better than 4 msec -- I rarely > see anything over 1 msec on my 10BaseT system at home, and typically > much better than that. Here's a short log: ping doesn't really tell you much, beacuse the packets are small and infrequent. I did some tests on the equivalent of 5 44.1KHz streams for 2 minuites with 256 sample packets. The far end just accepted them, did some simple processing and then sent the processed packet back. The latencies in microseconds were: Min:1160 (of 10 packets) Avg:1191 Max:70189 There was only one 70ms packet (and a few 50's and maybe a dozen over 10) but those would be real killers. This was on a lightly loaded 100mbit switched network. Theres a load meter on my hub and it didn't go above 10%. I tried the same test across a private gigabit network however and the latency was below solaris's ability to measure it (I don't know what that is though). There are no linux machines on that network, so I can't do a fair test. The linux machines were a dual PIII 866 and a PIII 650 The solaris machines are both quad 450Mhz ultraparc4's - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
On 2001-05-24 13:53 +0200, Jörn Nettingsmeier wrote: > even if larger switched networks are unusable, it would still be a > nice option to be able to connect two audio boxen via a dedicated > 100mb ether network to use their combined power for audio > applications. > at 20 US$ per card and 10$ for a crosslinked cat5 cable, this is a > dead cheap solution for studios. I'm definitely interested in this. I've been thinking about a distributed audio synthesis/processing protocol where events (MIDI messages) and audio data travel over UDP or TCP. The domain of application is LAN, not WAN. I assume the pessimistic figures mentioned earlier in this thread are for a WAN, not for a dedicated LAN. What I have in mind in the case of distributed synthesis is a master server that dispatches events to slaves, gets audio in return and does the mixing. -- André Majorel <[EMAIL PROTECTED]> http://www.teaser.fr/~amajorel/
Re: [linux-audio-dev] It's time to vote (n. 1)
Steve wrote: > > On Wed, May 23, 2001 at 07:25:37PM -0400, Paul Davis wrote: > > >> I'm just wondering, since I'm getting a .7 ms roundtrip time when > > >> pinging my other Linux system here, which is connected to this one > > >> by 100 Mbps ethernet through a 100 Mbps switch. Is that number > > >> for real? Because it seems almost too good. > > > > > >I get 150-250usec (yes, microseconds) roundtrip through 100mbps switch. > > > > is this on a previously quiescent connection (TCP or UDP) ? my > > impression is that once things get rolling round trip times are pretty > > good, but that moving a packet or two when there's been no traffic in > > a few msecs produces much worse numbers. my impression may be wrong. > > Over ethernet it seem to be only the first packet that is slow, probably > depends on the make of switch though. IIRC, there was a longer ping time for me even when I had two systems connected with a crossover cable and no switch/hub. > But as Paul said these times are too slow to be useful. Well, to be useful for what? For some purposes (such as audio playback over the network) less than a millisecond of delay is super. It would also be acceptable for a system that is running a software synthesizer and sending an audio stream to a multitrack recorder on another system. It might be better than using an analog or optical connection through a sound card(?). For software that is mostly running on one system, and trying to use a few plugins over a network connection, then it is not so good! - Jay Ts [EMAIL PROTECTED]
Re: [linux-audio-dev] It's time to vote (n. 1)
On Thu, May 24, 2001 at 01:53:56PM +0200, Jörn Nettingsmeier wrote: > > Over ethernet it seem to be only the first packet that is slow, probably > > depends on the make of switch though. Unswitched private networks should > > be fine. But as Paul said these times are too slow to be useful. > > are there any obstacles in this setup i have overlooked ? > from my experience, ping latency is well below 500 usecs. if that's > a measure for the actual audio latency, we'll be doing fine. Thats a measure of the minimum extra overhead, in practice it will be a lot higher as you will have to pull the data from the packet process it wrapper it back up again and send it back. Also remeber you have to reassemble the packets in the right order as the ordering is not guaranteed. I might try some benchmarks if anyone is interested. I'm guessing that you really need gigabit though. IP over SCSI or 1395 might be an option, but that's far more exotic. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
Steve Harris wrote: > > On Wed, May 23, 2001 at 07:25:37PM -0400, Paul Davis wrote: > > >> I'm just wondering, since I'm getting a .7 ms roundtrip time when > > >> pinging my other Linux system here, which is connected to this one > > >> by 100 Mbps ethernet through a 100 Mbps switch. Is that number > > >> for real? Because it seems almost too good. > > > > > >I get 150-250usec (yes, microseconds) roundtrip through 100mbps switch. > > > > is this on a previously quiescent connection (TCP or UDP) ? my > > impression is that once things get rolling round trip times are pretty > > good, but that moving a packet or two when there's been no traffic in > > a few msecs produces much worse numbers. my impression may be wrong. > > This is definatly true on ATM, the ramping up time is more like 30 seconds > though. > > Over ethernet it seem to be only the first packet that is slow, probably > depends on the make of switch though. Unswitched private networks should > be fine. But as Paul said these times are too slow to be useful. even if larger switched networks are unusable, it would still be a nice option to be able to connect two audio boxen via a dedicated 100mb ether network to use their combined power for audio applications. at 20 US$ per card and 10$ for a crosslinked cat5 cable, this is a dead cheap solution for studios. are there any obstacles in this setup i have overlooked ? from my experience, ping latency is well below 500 usecs. if that's a measure for the actual audio latency, we'll be doing fine. i must confess i don't see all the implications of net transparency for our glue api, but boy would it be cool. does the low-latency patch cover network drivers ? or can network traffic be stalled when the box is busy ? -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/
Re: [linux-audio-dev] It's time to vote (n. 1)
Paul Davis wrote: > > >> I'm just wondering, since I'm getting a .7 ms roundtrip time when > >> pinging my other Linux system here, which is connected to this one > >> by 100 Mbps ethernet through a 100 Mbps switch. Is that number > >> for real? Because it seems almost too good. > > > >I get 150-250usec (yes, microseconds) roundtrip through 100mbps switch. > > is this on a previously quiescent connection (TCP or UDP) ? my > impression is that once things get rolling round trip times are pretty > good, but that moving a packet or two when there's been no traffic in > a few msecs produces much worse numbers. my impression may be wrong. > > i'd also like to point out that the lowest value mentioned above is > more than 10% of the total time available to process a 64 frame chunk > of audio at 48kHz :) > > --p here is a typical ping on my local unswitched 100mb/s cat5 network: nettings@kleineronkel:~ > ping spunk PING spunk.villakunterbunt.netz (192.168.200.200): 56 data bytes 64 bytes from 192.168.200.200: icmp_seq=0 ttl=255 time=0.298 ms 64 bytes from 192.168.200.200: icmp_seq=1 ttl=255 time=0.246 ms 64 bytes from 192.168.200.200: icmp_seq=2 ttl=255 time=0.243 ms 64 bytes from 192.168.200.200: icmp_seq=3 ttl=255 time=0.237 ms 64 bytes from 192.168.200.200: icmp_seq=4 ttl=255 time=0.253 ms 64 bytes from 192.168.200.200: icmp_seq=5 ttl=255 time=0.236 ms 64 bytes from 192.168.200.200: icmp_seq=6 ttl=255 time=0.232 ms 64 bytes from 192.168.200.200: icmp_seq=7 ttl=255 time=0.243 ms --- spunk.villakunterbunt.netz ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max = 0.232/0.248/0.298 ms if the first (longer) round-trip time is a measure for the case that paul mentioned, there should be no problem with newly initiated connections. what is the chunk size that we will typically expect for audio connections ? then we could check with ping -s for slightly more realistic figures.. -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/
Re: [linux-audio-dev] It's time to vote (n. 1)
On Wed, May 23, 2001 at 05:31:59PM -0700, Dan Hollis wrote: > Worst case latency was 4.973msec and average was 1.195msec. Thats round > trip mind you. > > This is all super-cheap-ass hardware, too. The PCI 100bt cards are $15/ea > and the 24 port full duplex switch was $400. > > I seem to recall someone claiming that 100baseT was "much too slow" for > audio? Well, seen as most pro users are demanding <5ms total system latency, 4-5ms for the transport alone isn't really useful. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
On Wed, May 23, 2001 at 07:25:37PM -0400, Paul Davis wrote: > >> I'm just wondering, since I'm getting a .7 ms roundtrip time when > >> pinging my other Linux system here, which is connected to this one > >> by 100 Mbps ethernet through a 100 Mbps switch. Is that number > >> for real? Because it seems almost too good. > > > >I get 150-250usec (yes, microseconds) roundtrip through 100mbps switch. > > is this on a previously quiescent connection (TCP or UDP) ? my > impression is that once things get rolling round trip times are pretty > good, but that moving a packet or two when there's been no traffic in > a few msecs produces much worse numbers. my impression may be wrong. This is definatly true on ATM, the ramping up time is more like 30 seconds though. Over ethernet it seem to be only the first packet that is slow, probably depends on the make of switch though. Unswitched private networks should be fine. But as Paul said these times are too slow to be useful. - Steve
Re: [linux-audio-dev] It's time to vote (n. 1)
On Wed, 23 May 2001, Paul Davis wrote: > >I get 150-250usec (yes, microseconds) roundtrip through 100mbps switch. > is this on a previously quiescent connection (TCP or UDP) ? my > impression is that once things get rolling round trip times are pretty > good, but that moving a packet or two when there's been no traffic in > a few msecs produces much worse numbers. my impression may be wrong. That was on a rather busy ISP backbone. You got me interested in worst case numbers, so I fired up a full duplex 100bt ttcp session of ~9500kbyte/sec both ways between two hosts through a full duplex 100bt switch, then pinged several hundred packets from a third host also on the switch. All the hosts were moderately loaded ISP servers. Worst case latency was 4.973msec and average was 1.195msec. Thats round trip mind you. This is all super-cheap-ass hardware, too. The PCI 100bt cards are $15/ea and the 24 port full duplex switch was $400. I seem to recall someone claiming that 100baseT was "much too slow" for audio? -Dan
Re: [linux-audio-dev] It's time to vote (n. 1)
> I'm just wondering, since I'm getting a .7 ms roundtrip time when > pinging my other Linux system here, which is connected to this one > by 100 Mbps ethernet through a 100 Mbps switch. Is that number > for real? Because it seems almost too good. Yes it is -- see the Stanford-Berkeley RTT's in Section 8.5 of the paper links I sent along to the newsgroup earlier today; those are going through 24 hops round-trip (see traced route in Table 2), yet the total RTT is 3.6 ms -- subtract out speed of light across the Bay and back, and there isn't that much time left for those 24 boxes to do their thing :-). Of course, that measurement is 60 measurements done at 1-second intervals, taken during an uncongested minute -- that's why the standard deviation in the table is so low. Pick a period with intense congestion, and its a whole different story (see Table 5 and Section 8.4 to get a feel ...). - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
Re: [linux-audio-dev] It's time to vote (n. 1)
>> I'm just wondering, since I'm getting a .7 ms roundtrip time when >> pinging my other Linux system here, which is connected to this one >> by 100 Mbps ethernet through a 100 Mbps switch. Is that number >> for real? Because it seems almost too good. > >I get 150-250usec (yes, microseconds) roundtrip through 100mbps switch. is this on a previously quiescent connection (TCP or UDP) ? my impression is that once things get rolling round trip times are pretty good, but that moving a packet or two when there's been no traffic in a few msecs produces much worse numbers. my impression may be wrong. i'd also like to point out that the lowest value mentioned above is more than 10% of the total time available to process a 64 frame chunk of audio at 48kHz :) --p
Re: [linux-audio-dev] It's time to vote (n. 1)
On Wed, 23 May 2001, Jay Ts wrote: > I'm just wondering, since I'm getting a .7 ms roundtrip time when > pinging my other Linux system here, which is connected to this one > by 100 Mbps ethernet through a 100 Mbps switch. Is that number > for real? Because it seems almost too good. I get 150-250usec (yes, microseconds) roundtrip through 100mbps switch. Havent tried gigglebit ethernet yet. -Dan
Re: [linux-audio-dev] It's time to vote (n. 1)
> > > Now this is what we call an imagination! I hope not to imply a > > daydream, though. Buy this man a drink! > > No one can accuse me of setting other people's goals too low :) Since we are having fun dreaming, I've been wondering about how much latency is in 100 Mbps or 1 Gbps networking? In other words, how "bad" would it be if parts of the graph were located on one machine, and parts on another. An example: having a software synth running on one machine, as a LAAGA "soundbox", communicating with a host program on another. Instead of using standard MIDI and digital audio, it would use Fast Ethernet or Gigabit ethernet. I'm just wondering, since I'm getting a .7 ms roundtrip time when pinging my other Linux system here, which is connected to this one by 100 Mbps ethernet through a 100 Mbps switch. Is that number for real? Because it seems almost too good. Plus, would there be any limitation preventing the current design from networking over ethernet or Internet using sockets? (Latency issues aside at this point; I'm just thinking about streaming audio or a free Internet Phone for Linux, with an open Internet protocol and RFC that would allow it to work with Macs, Windows, et. al.) - Jay Ts [EMAIL PROTECTED]
Re: [linux-audio-dev] It's time to vote (n. 1)
> Now this is what we call an imagination! I hope not to imply a > daydream, though. Buy this man a drink! No one can accuse me of setting other people's goals too low :) Tom
