Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsxfer3.itd.umich.edu!portc01.blue.aol.com!newsstand.cit.cornell.edu!news.acsu.buffalo.edu!acsu.buffalo.edu!whitley From: whitley@cs.buffalo.edu (John Whitley) Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc,comp.sys.sgi.misc Subject: Re: no such thing as a "general user community" Date: 21 Mar 1997 22:53:24 GMT Organization: State University of New York at Buffalo/Comp Sci Lines: 53 Message-ID: <5gv3h4$968@prometheus.acsu.buffalo.edu> References: <331BB7DD.28EC@net5.net> <5gs1de$k3s@flea.best.net> <5gsgsm$c5l@gazette.engr.sgi.com> <5gt4n5$9cc@flea.best.net> Reply-To: whitley@cs.buffalo.edu NNTP-Posting-Host: hadar.cs.buffalo.edu NNTP-Posting-User: whitley Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37512 comp.unix.bsd.bsdi.misc:6419 comp.sys.sgi.misc:29339 Matt Dillon <dillon@flea.best.net> wrote: >:Doug Cook <cook@candiru.engr.sgi.com> wrote: >:>I disagree. Latency is the main bottleneck for multitrack sound >:>editing, particularly where many tracks are involved and short >:>edits are permitted. >:> >:> -Doug > > Only if the software is badly designed. 16 bits at 44KHz is > barely 100KBytes/sec. One disk alone can do 8 MBytes/sec > in linear transfer rate. Even if you have to seek 20 times a second > you will still get 4 MBytes/sec over the entire disk... and > that's ONE disk. If you have, say, four 2G disks dedicated > to your edit stream, we're talking around 120 to 160 FULL-bandwidth > tracks running in parallel without any fancy filesystem support. > > -Matt A) Oh, yes, let's just do it all in the application software. Hell, let's just chuck out the operating system and compiler overhead all-together and write in assembly code. "Well designed" software should be able to coexist with other "well designed" sfotware without any resource contentions, eh? :-PPP B) Your "four 2G disks" assumes one of two things: that the filesystem supports disk striping (such as... XFS) or that the application must handle the multiple disk streams itself (with the necessary user setup and programmer overhead. what-ever.). C) Four 2G disks more or less implies "fixed studio installation". I agree that high bandwidth makes life easier, but it is no solution. D) FIFOs increase latency. Latency is a killer in realtime audio applications. E) This doesn't provide a _guarantee_. A number of critical audio applications where systems like this will be employed require certainty, not supposition. F) One phrase: "Realtime multimedia web serving." May not be huge now, but just wait a week or two at this pace... G) Another phrase: "Realtime interactive computer music." Escaped from the DSP card cage and coming to general purpose hardware near you... H) You would have been right had you tried to say "a minority of users require bandwidth guarantees in the here and now". What you did say is that "no one needs bandwidth guarantees except video editors." This statement is wrong, period. -- John