[linux-audio-dev] New speakers being developed.
FYI. I'm in South Korea and the other day while browsing the TV I saw a short article about a new version of speaker that is being developed in Seoul at one of the Universities. The interesting thing about this speaker is that it has no moving parts. It is essentially a sheet of 2mm plastic with a signal being passed through it. The developers were saying that they have had very good results with treble and are now concentrating on the Bass side. The scope of this new technology is amazing. A couple of examples. - Your screen is your speaker. - The walls of a theatre or auditorium are covered in this stuff so that you have sound coming from everywhere. Let your imagination go wild. Lastly they were saying that they have had a lot of interest from major manufacturers already and they expect that the product will be on shelves within 6 - 8 months. Kind of wierd huh ;-] Kiaora. -- Patrick Shirkey - Manager Boost Hardware. Http://www.boosthardware.com for latest stock and prices. Importing Korean Computer Hardware to New Zealand.
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
[linux-audio-dev] test - ignore
Re: [linux-audio-dev] a central problem with *any* Port model?
Tom Pincince wrote: > > > > But wait a minute! Oh my, this is much worse than I thought. Much > > > worse. There isn't *any* way to monitor the input of a Port in > > > general! If it happens to be a port on a Driver that is controlling an > > > audio h/w interface, then its possible. But in the general case, the > > > notion of monitoring a Port is nonsensical - there is no mechanism to > > > do it. > > > > > > Gulp. This seems bad. > > > > > > How can anyone build a disk recorder that cannot monitor its input > > > effectively? > > > > > > I've not understood what's the problem... > > > > > > I see you've problems if you limit port data type to float ;-). > > > > > > Someone can explain which other problems exists? > > Monitoring means sending a signal to an audio interface output. In the > current model signals go from output ports to input ports, so the only > signals that can access the input port of an audio interface output come > from plugin output ports. There is currently no defined way of sending > the contents of an input port to another input port, so there is no way > to monitor the signal that is feeding a plugin. Some ascii art: +-+ +-+ | HD | | CAPTURE PCM | +-===-+ +-===-+ || | +--+ |/ +---===---+ |`-+ | PLUGIN || +---===---+ +-===--+ | | PLAYBACK PCM | +-===-++--+ | HD | +-+ === are ports +--+ | | are soundboxes +--+ -- are flows With the model I've proposed this is natural: we have ports (where buffers live) and we have flows from/to ports (one ports, many flows). Note that PLAYBACK PCM is not *inside* PLUGIN, it's a read flow of its input port. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good!
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] Gigabit ethernet to stream audio
> -Original Message- > From: Steve Harris [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 24, 2001 9:16 AM > To: [EMAIL PROTECTED] > Subject: Re: [linux-audio-dev] Gigabit ethernet to stream audio > > > On Thu, May 24, 2001 at 07:20:59AM -0700, Jay Ts wrote: > > Vincent wrote: > > > > > > Maybe this can be of interest, regarding the discussion > > > about audio over ethernet: > > > http://www.itworld.com/Net/1748/NWW010402feat/ > > Note, they are using Ethernet, not TCP/IP or UDP. ethernet and tcp/ip are different layers, ethernet is somewhere in the range 1-2, tcp/ip in 3-6 (or something like that). even if they don't use tcp/ip (the article does not say) they have to use some protocol upon ethernet. However the following sentence: "The Disney network makes extensive use of standard protocols, including SNMP." suggests that they use tcp/ip (standard protocols). I can imagine that they also use other protocols (SMB, IPX etc.) to continue nitpicking: udp is part of tcp/ip (see e.g. http://info.acm.org/crossroads/xrds1-1/tcpjmy.html) erik
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] a central problem with *any* Port model?
> > But wait a minute! Oh my, this is much worse than I thought. Much > > worse. There isn't *any* way to monitor the input of a Port in > > general! If it happens to be a port on a Driver that is controlling an > > audio h/w interface, then its possible. But in the general case, the > > notion of monitoring a Port is nonsensical - there is no mechanism to > > do it. > > > > Gulp. This seems bad. > > > > How can anyone build a disk recorder that cannot monitor its input > > effectively? > > > I've not understood what's the problem... > > > I see you've problems if you limit port data type to float ;-). > > > Someone can explain which other problems exists? Monitoring means sending a signal to an audio interface output. In the current model signals go from output ports to input ports, so the only signals that can access the input port of an audio interface output come from plugin output ports. There is currently no defined way of sending the contents of an input port to another input port, so there is no way to monitor the signal that is feeding a plugin. Tom
Re: [linux-audio-dev] 64 bit float or integer
I let this one float by but it stuck in my mind so... > you need to drive integers with maximum gain (just like tape > recorders) in order to have maximum resolution. for example, using a > 24 bit ADC at half the maximum input level will make it sound like > 12 bits. same applies to a plugin that takes integers. > so with integers, there will be a lot of normalization going on. Reducing the input to an a/d by 50%, or 6db, reduces the digital resolution by only 1 bit. Tom
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] Gigabit ethernet to stream audio
On Thu, May 24, 2001 at 07:20:59AM -0700, Jay Ts wrote: > Vincent wrote: > > > > Maybe this can be of interest, regarding the discussion > > about audio over ethernet: > > http://www.itworld.com/Net/1748/NWW010402feat/ Note, they are using Ethernet, not TCP/IP or UDP. - 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] Gigabit ethernet to stream audio
Vincent wrote: > > Maybe this can be of interest, regarding the discussion > about audio over ethernet: > http://www.itworld.com/Net/1748/NWW010402feat/ This is a good example of the kind of thing I'd like to be able to do with Linux before too long. Or at least send an audio stream out to the computer in the living room, so I can listen from there. Heh, I like this quote: This real-time nature of the audio signal is important to Disney. In the new Tokyo park, staffers had to develop a ride that went through a simulated volcano, equipped with 30 5,000-watt amplifiers driving various subwoofers and other large speakers. All of this is controlled over the park Ethernet system, including transmission of the sound effects themselves. "When we first demonstrated this in our California lot, we kept setting off car alarms all over the neighborhood," Tamalunas says. Jay Ts [EMAIL PROTECTED]
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/
[linux-audio-dev] Gigabit ethernet to stream audio
Maybe this can be of interest, regarding the discussion about audio over ethernet: http://www.itworld.com/Net/1748/NWW010402feat/ Sorry to have started a new thread, but I couldn't find the right msg to reply to Regards Vincent
Re: [linux-audio-dev] more fundamental questions
On Wed, May 23, 2001 at 05:24:55PM -0400, [EMAIL PROTECTED] wrote: > Jay Ts wrote: > > I did a little more thinking on this and realized that MIDI is essentially > > a control signal, and maybe it would make sense, in a general way, to > > include control signals in the design in addition to audio, and then > > make MIDI (or some cooked version of it) a class of control signal. > > Control signals are almost a must for synthesis. Two thirds and up of > your signals in a patch can be control, so running those at > control-rate gives you a factor of three in speed. Whether they're > passed between applications quite as much as that, which is what LAAGA > cares about, I don't know. I don't really thin that control signals in the sense of CV are going to be that important to LAAGA, they should be implementable via named signals as discussed earlier. - Steve
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
