From: owner-bass-digest (Bass Appreciation Digest) To: bass-digest@lunch.engr.sgi.com Subject: Bass Appreciation Digest V2 #142 Reply-To: bass Errors-To: owner-bass-digest@lunch.engr.sgi.com Precedence: bulk Bass Appreciation Digest Wednesday, April 19 1995 Volume 2, Number 142 Important Addresses: Submissions to the list: bass@lunch.engr.sgi.com (or reply to this message). Adds/removes/archives: bass-digest-request@lunch.engr.sgi.com Real, live person: owner-bass@lunch.engr.sgi.com Topics: Jitter Digital jitter Re: Wiring your audio room with Ethernet Re: Wiring your audio room with Ethernet Re: Digital jitter Re: Wiring your audio room with Ethernet Re: Digital jitter Re: Digital jitter Re: RS 18": What do you think? Re: Wiring your audio room with Ethernet Re: RS 18": What do you think? ---------------------------------------------------------------------- Date: Wed, 19 Apr 1995 08:03:09 -0400 From: Dan Hildebrand Subject: Jitter > Date: Tue, 18 Apr 1995 19:39:14 -0400 (EDT) > From: petroca@acasun.eckerd.edu (Chris A. Petro) > Subject: Re: Bass Appreciation Digest V2 #137 > > > > as I recall, a single-speed runs at standard audio speeds. > > > > Exactly. With quad-spin drives becoming common, it should be easy to feed > > the data across a LAN faster than the output DAC needs it. > > ohhhh... you mean actually running across ethernet. I thought you were > just going to use the cable to send S/P-DIF or something. yeah, faster > than necessary would definitely be a good idea in that case, given the > irregularity of getting it across the net. Yes, as long as I deliver the packets of audio data faster than the DAC is clocking them out, no "outages" will occur. > I don't have prices, but in case you don't have specs on the chips (or for > anyone else interested)... > CS8401A/2A Digital audio interface transmitter (supports > AES/EBU, IEC958, S/P-DIF, EIAJ CP-340 formats) > CS8411/12 Digital audio interface receiver (same formats) > CS4303 107 dB, stereo, 18-bit sigma-delta DAC with 100 dB > S/(N+D) specification > CS4328 CS4303 with interpolator and analog filter > CS8425 A-LAN (audio local area network) transceiver > (I2C bus, parallel interface, or standalone > transceiver) The parallel interface on the CD8425 looks interesting for direct opto-coupled connection to a PC parallel port and a bit of junk logic. Where can I get a Crystal databook? Does anyone have a phone number for them? > > Am I being overly > > paranoid (or misinformed?) to think that S/P-DIF might be a deliberate > > effort to create problems that need more hardware to solve? :-) > > conspiracy alert! actually, I don't know for sure how S/P-DIF is > implemented, but I assume it's crystal-controlled. Nope - a PLL extracts the clock from a serial data stream and is prone to drift depending on the data stream contents. Yechhh! > the only problem might > be that the DAC could still have jitter. of course, I doubt that anyone > could identify that by ear anyway... The DAC should not have any inherent jitter. With a crystal clock directly driving the sample interval, it should have virtually 0 jitter. Regarding whether or not it is audible, it's interesting to read the various opinions. If I'm going to be building my own, why implement a design that fundamentally has this problem when a simpler design avoids it altogether? Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd. http://www.qnx.com/~danh 175 Terence Matthews phone: (613) 591-0931 (voice) Kanata, Ontario, Canada (613) 591-3579 (fax) K2M 1W8 ------------------------------ Date: Wed, 19 Apr 1995 08:12:03 -0400 From: Dan Hildebrand Subject: Digital jitter > Date: Tue, 18 Apr 1995 18:07:59 -0700 > From: Paul Kendall > Subject: Re: Digital jitter > > But you *still* have to have a good transport, right? Any uncertainty during > the actual read process will end up in the bit stream and will not be removed > by reclocking the data through a FIFO. This is a popular misconception. Data read from CD (CDROM or Audio CD) does not need to be read with any precision in rotational speed, whatsoever. The data comes off in blocks, with error encoding so that errors can be detected and re-read from the media to attempt to get a clean read. With error-check blocks in memory, they are then clocked at a crystal controlled rate either to the built-in DAC, or out through some sort of serial interface to an external DAC. The problem here is that the encoding approach used to sent the clock intermixes with the data to the external DAC introduces jitter that is not present when driving the internal DAC. You don't need a "jitter fixer" for a internal DAC since it doesn't have the problem in the first place. > The reclocking will give you precise > time alignment to your high-precision oscillator, but will not cure any > errors introduced by jitter in the actual read circuit. (That is, due to > jitter in the read clock, the transport sends out a 1 when it should have > been a 0. Any working (ie: not broken) transport almost always gets the right data from the media (1 wrong bit in 10 CD's according to some tests I've seen). When was the last time your CDROM drive read data incorrectly? :-) I suspect there's a strong left-over turntable mentality out there that some CD transport vendors are capitalizing on by selling incredibly precise transport mechanisms when it literally makes no difference to the precision of anything. Bits are bits, it's in communicating the bits over SPDIF to a DAC and in the DAC itself where the error creeps in. > It's now in the bit stream so reclocking will *still* give you a 1, > albeit a nicely time-aligned 1.) > > Am I missing something here? The problem is that clock extraction from an SPDIF data stream is not nearly as precise as having a crystal clock at the DAC-end of the interface. Hence the aftermarket in jitter fixers, etc. Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd. http://www.qnx.com/~danh 175 Terence Matthews phone: (613) 591-0931 (voice) Kanata, Ontario, Canada (613) 591-3579 (fax) K2M 1W8 ------------------------------ Date: Wed, 19 Apr 95 12:57:44 BST From: charles@anatomy.ucl.ac.uk (Charles King) Subject: Re: Wiring your audio room with Ethernet Jonas Palm wrote: >Christopher Petro wrote: > >>which will probably still sound pretty ugly, since any sort of compression >>messes the audio up. I have yet to see a decent video mpeg. very few >>compression programs do a very good job. 3d-studio, btw, does an >>excellent job of jpeg compression. you have to look hard to see the >>artifacts in the picture, instead of having to look hard to see the >>picture through the artifacts. they might have gotten it working pretty >>nice, but I'm sure it doesn't sound very good compared to the original. > >Quite sure? >Maybe you should discuss this with jj over at the rec.audio newsgroups.... >Don't kick it until you've tried it. I've made recodings to DCC which uses >PASC which is essentially MPEG at 384kbits/sec (roughly 1:4 compression), >and using music, I couldn't make it show _any_ compression artifacts. >And I had ideas about how I could make it show weaknesses. I feel obliged to point out that jj works for AT&T, a company which is actively involved in bidding on contracts for audio compression for film (or they were - it looks like Dolby has won), so his views are not exactly unbiased. Compression can indeed sound good, and some schemes are very good indeed. To date, however, every compressor falls down somewhere, usually with transients containing important high-frequency harmonics. Lossy compression works, and is quite suitable for the quality of sound that is demanded by the typical consumer (a scenario in which the sound quality is determined by the lousy speakers and indifferent electronics found in most low-fi systems rather than the quality of the digital source). If sound quality matters sufficiently for you to pour in a lot of money and/or time in getting your system sounding right (which, I would imagine, is true of most of the people on this list), then I just can't see the point of using anything less than a full 1.5 Mbit stream as the source. I think it's generally better to go forwards rather than backwards. Charles King ------------------------------ Date: Wed, 19 Apr 95 13:10:04 BST From: charles@anatomy.ucl.ac.uk (Charles King) Subject: Re: Wiring your audio room with Ethernet Dan Hildebrandt wrote: >When I hear of S/P-DIF jitter fixer boxes, and people reclocking the D-A's >with PLL's, etc, etc, I can't help but think that the S/P-DIF interface is >broken if it has these problems (ie: not sending a clock with the data). A >packetized data stream fed across an optical interface to separate the >digital and analog grounds, with a crystal clock walking the data through >the DAC should be trivial to implement, jitter-free. The problem really lies with the digital interface receiver (DIR). The DIR has to be able to handle a range of sampling frequencies (32, 44.1, 48) and so has to have a PLL with a sufficiently wide range to cope with this. The best way to do this would be to have 2 or 3 external crystals linked to VCXOs to reclock the data, but this is expensive, and most of the research in digital audio is aimed at getting prices down. Therefore, most common DIRs use a much simpler PLL which is vulnerable to introducing jitter. The best commonly-found DIR is the Crystal 8412, which typically produces around 200ps of jitter. Thus, the problem is not with the S/PDIF interface per se, it's with the implementation of the receiver chips. Analogue Devices have already come up with a way of eliminating jitter completely, though it's based on an asynchronous sample rate converter which is relatively expensive (this is at the heart of the Audio Alchemy DTI pro - an expensive toy which is of little value as the signal still has to go through the DAC's DIR, where it is rejittered, the only sensible place to stick the AD chip is between the DIR and the digital filter as outlined in The Audio amateur last year). There is some point in reclocking the data stream prior to the DIR, as jitter in the input data stream will be reproduced by the DIR's tolerant PLL, but this will not have a major effect (I built one of these things, mounted it in my DAC right next to the DIR and couldn't hear any difference). Charles King Sheesh! Not much to do with bass, eh? ------------------------------ Date: Wed, 19 Apr 95 13:36:21 BST From: charles@anatomy.ucl.ac.uk (Charles King) Subject: Re: Digital jitter Paul Kendall writes: >But you *still* have to have a good transport, right? Any uncertainty during >the actual read process will end up in the bit stream and will not be removed >by reclocking the data through a FIFO. The reclocking will give you precise >time alignment to your high-precision oscillator, but will not cure any >errors introduced by jitter in the actual read circuit. (That is, due to >jitter in the read clock, the transport sends out a 1 when it should have >been a 0. It's now in the bit stream so reclocking will *still* give you a 1, >albeit a nicely time-aligned 1.) > >Am I missing something here? You are indeed. Digital audio has a substantial amount of error correction and concealment built in. In fact, any transport that requires the decoding circuitry to engage its concealment techniques is certainly due for the scrapheap, anyway. Contemporary laser technology is more than capable of ensuring that no actual bit errors occur in reading the data off the disc, though there are several ill-informed audio journalists who seem to think that this is still a problem (it might have been 15 years ago, when the technology was first designed, but not anymore). Charles King ------------------------------ Date: Wed, 19 Apr 1995 09:43:02 -0400 (EDT) From: kodis@daacdev1.stx.com (John Kodis) Subject: Re: Wiring your audio room with Ethernet Charles King wrote: > > I feel obliged to point out that jj works for AT&T, [...] > so his views are not exactly unbiased. Perhaps not unbiased, but exceedingly well informed. > Lossy compression works, and is quite suitable for the quality of sound that > is demanded by the typical consumer [...]. I just can't see the point of > using anything less than a full 1.5 Mbit stream as the source. I'd have to agree. However, rather than concluding that all compression is a bad thing, I'd be curious about how much compression can be achieved on typical audio sources without incuring *any* loss? It seems that the correlation between the two channels of a typical recording would be enough to insure that there is plenty of redundancy inherent in the signal being recorded. Does anyone (jj, perhaps) have a feel for what sort of compression ratios can typically be achieved losslessly? - -- John Kodis. ------------------------------ Date: Wed, 19 Apr 1995 10:01:43 -0400 (EDT) From: "Bill Flowers" Subject: Re: Digital jitter Dan Hildebrand wrote: > I suspect there's a strong left-over turntable mentality out there that > some CD transport vendors are capitalizing on by selling incredibly precise > transport mechanisms when it literally makes no difference to the precision > of anything. Bits are bits, it's in communicating the bits over SPDIF to a > DAC and in the DAC itself where the error creeps in. Or maybe the manufacturers are just saying the transport is "incredibly precise" when in actual fact there is little or no difference between it and most other transports. In my work (designing and writing file systems) I've played with various CD-ROM drives for countless hours. Some were very expensive, some dirt cheap. All could read the data without error. - --- W.A. (Bill) Flowers waflowers@qnx.com QNX Software Systems, Ltd. phone: (613) 591-0931 (voice) 175 Terence Matthews (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8 ------------------------------ Date: Wed, 19 Apr 1995 10:01:53 -0400 (EDT) From: kodis@daacdev1.stx.com (John Kodis) Subject: Re: Digital jitter Andre write: > All you need to do this is hardware flow-control in S/PDIF, and this > solution has been known since the dark ages when people figured out > serial transmission. All other solutions are just so much Band-Aids > and kludges. Probably so, but not all kludges are created equal. The trouble with using a fancier protocol is that it'll be tough to get the industry to agree on a new standard which will obsolete all existing equipment to achieve what is widely percieved as a minor problem. Let me propose an alternative: a big FIFO. Stick with the existing S/P-DIF (or whatever) interface, but tweek the source (CD deck, DAT, whatever) to run a little fast -- say 0.1% above nominal. This should be a simple after-market mod to nearly any CD transport. Then, on the receiving end, read the data into a big FIFO, and clock it out to the D2A converter using a precise local clock. You would only need a megabyte or so to buffer the overrun on an entire CD at this rate. That's not even a hundred dollars worth of memory: less cost than even an entry-level audiofool-approved digital interconnect. Am I overlooking anything, or would something this simple really work? - -- John Kodis. ------------------------------ Date: Wed, 19 Apr 1995 10:12:44 EST6EDT From: jdudeck@simcsg.sim.org Subject: Re: RS 18": What do you think? > On Tue, 18 Apr 1995 jdudeck@simcsg.sim.org (that's I) wrote: > > > Agreed. But actively-assisted designs are also interesting and not > > necessarily anathema. Doug P: > Of course this is a viable route. Except . . . What you have done a > good job of in your prior posting, John, is describe a Bag End ELF 18 > system. Yes, I had that in mind when I was writing. I've got the marketing blurbs at home somewhere. I didn't fully understand from what I read how the Bag End is designed, so I didn't want to say something unfounded. > And the smart part of their circuit clamps maximum output to the > driver when it exceeds the mechanical and thermal limits of the driver. > The Bag End is a wimpy deep-bass reproducer compared to other > methodologies. Ok. I didn't know about the limiters in the Bag End. That makes sense, though, since they are intended for use in music performance in clubs. That would make them do well up to thier limits, and then protect themselves. I think the main selling point for the Bag End is the relatively compact size and low-end extension compared to other 18" sub systems, making it appealing for the road. The tradeoff seems to be peak SPL and efficiency. But efficiency isn't an important factor for performance in small clubs, and as long as the SPL is sufficient for the venue, that's not an issue, either. So I agree that if the goal is a subwoofer for a home music system, the RS 18" isn't ideally suited, and if you force it into operating in that range via active EQ you are pushing it where it isn't intended and leaving it unused in the range it was designed for. Of course we use Pentiums all the time in desktop PC's, so why not? John Dudeck SIM International Cooperative Systems Group Tel: 704-588-6100 jdudeck@simcsg.sim.org EasyLink: 62013975 - -- "It's loss of courage that is the reason for the downfall of each civilization." -- Alexander Solzhenitsyn ------------------------------ Date: Wed, 19 Apr 1995 10:17:07 -0400 From: ledzep@elmo.lz.att.com (Carl Muhlhausen LZ 1B-115L x3052) Subject: Re: Wiring your audio room with Ethernet charles@anatomy.ucl.ac.uk writes: > I feel obliged to point out that jj works for AT&T, a company which is So what! I feel obliged to point out that jj has always been one of the strongest advocates of rigorous blind testing of any compression scheme and any claims he might make for his algorithm vs any competing algorithm would be based on such testing and not because AT&T is telling him to. jj has never claimed (to my knowledge) that his or any other compression schemes are transparent to all audio signals and has given examples of sounds in which his and other compression schemes are not transparent. I think it's uncalled for to accuse a scientist of bias and question his motives with ad-hominem arguments just because his work is financed by a company with a commercial stake in the outcome. > actively involved in bidding on contracts for audio compression for film > (or they were - it looks like Dolby has won), so his views are not exactly > unbiased. Compression can indeed sound good, and some schemes are very good > indeed. To date, however, every compressor falls down somewhere, usually with > transients containing important high-frequency harmonics. > I'd like to see documentation where jj has ever claimed otherwise. Carl - not speaking for jj, AT&T or in support of lossy compression. ****************************************************************************** Carl W. Muhlhausen Note new id--> ledzep@elmo.lz.att.com Rm. 1B-115L (908)-576-3052 AT&T Bell Laboratories 307 Middletown-Lincroft Rd. Lincroft, NJ 07738 ******************************************************************************** ------------------------------ Date: Wed, 19 Apr 1995 10:29:41 EST6EDT From: jdudeck@simcsg.sim.org Subject: Re: RS 18": What do you think? > > The Bag End is a wimpy deep-bass reproducer compared to other > > methodologies. > > I can see this. Also, I guess I would like to avoid active electronics > as much as possible. I don't see any other way to get it to perform down in the sub-woofer range. > > And weighting the cone to extend response, as John Busenitz has suggested, > > has its penalities as well. Sensitivity will drop, and the only antidote > > to that is increasing drive, which brings us right back to the thermal > > capabilities of the driver. I don't know who designed this RS driver, but > > whoever it was seemed to have bass-guitar amplification in mind. It just > > doesn't fit as a subwoofer in an audio system. > > I understand what you are saying, but I don't understand why this woofer > won't do a good subwoofing job. Fs is 16.5 Hz. That's pretty low, isn't > it? And it has a nice big piston area. Is it's downfall the low Qts? > How does that really limit low frequency output? With any high-pass system (which is what a woofer+enclosure is), you have a rolloff slope and you have its behavior at the "knee" of the rolloff which is determined by the system Q. Maximally flat is a Q of .707, critically damped is .5, and below that is overdamped. (You knew that). The issue is the performance around the knee of the curve. When the knee is down in the low-bass range, then the Q is going to be the major factor in determining the response in the range of interest. If the Q is too low, the response will start rolling off higher. A couple octaves below the knee it doesn't matter what the Q is because it will pretty much be down 24 db. It's not that the Q limits the low frequency output, it's that it is in the rolloff region of the high-pass transfer function, so you are getting reduced response to the input signal, which you can boost if you want to overcome the rolloff. John Dudeck SIM International Cooperative Systems Group Tel: 704-588-6100 jdudeck@simcsg.sim.org EasyLink: 62013975 - -- "It's loss of courage that is the reason for the downfall of each civilization." -- Alexander Solzhenitsyn ------------------------------ End of Bass Appreciation Digest V2 #142 *************************************** A non-digest (direct mail) version of this list is also available; to subscribe to that instead, send the command lines: unsubscribe bass-digest subscribe bass end in the body of a message to majordomo@lunch.engr.sgi.com. Thanks and enjoy the list!