Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing

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

Subject: Re: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
From: Richard C. Burnett (burnett_AT_tality.com)
Date: Fri Jun 14 2002 - 20:58:40 EEST


> Which is enough to reconstruct the sine wave if the output is through a proper
> post-DAC filter.

But given a 20Khz sine wave at say 40Khz sample rate, and 90 degree phase
shift (sorry about that) you won't get an accurate level sample of the
signal. Add to this that the clock drift and sine wave, which are much
closer together than say a 20khz and a 200Khz signal, you are going to get
amplitude modulation from the different sample points. Have you ever
plotted a sine wave where you you don't pick enough points to show the
real shape? It's the same principle.

> Hmmm. Wouldn't that be 90 degrees out of phase for the sample to occur at the
> zero crossing? However, if the sample occurs at the zero crossing for any
> given frequency in the composite, unless the sampled frequency is exactly at
> the sampling frequency (above normal audibility) the next sample won't be at
> zero crossing.

But the higher your sampling rate, the more you are guaranteed not to miss
a max point or a min point, because when the signal is in those ranges,
it's able to grab many points.

> But the rules for digital sampling have always been that the highest samplable
> frequency is less than half the sampling rate (Nyquist's Theorem). Not less
> than or equal to.

Actually I read equal to in one of my text books, but that is beside the
point. It means that you can 'detect' frequencies at that frequency, but
it doesn't mean you can accuratly reproduce them. Even at say 18kHz
sampling at 40kz you would see essentially a beat frequency (I think that
is the term) as the sampling point is different in each cycle, and not
enough to capture the max/min every time.

> And at what frequency does the ear's many bandpass filtered detectors lose
> frequency resolution? Well, to answer that one, let me tell you about the
> radio engineer that I know who can tune CCTV monitors' horizontal
> oscillators by ear -- thanks to a steep notch he has at 15.735kHz in his
> hearing. He can hear clearly above that notch, and below that notch, but has
> almost zero hearing in the null. He was able to get the horizontal oscs to
> within a couple or three Hz. That would be an unusal accident of his
> auricular structures to get that steep of a notch, but such individuals do
> exist. I _wish_ I had a steep notch at 15.735kHz, as singing flybacks give
> me a headache!
>
> While I understand the stated reasons for 192ksps, I wonder if the effects are
> really audible. Double-blind testing would be required.

I've done the test. I listened to a CD recorded SACD and a standard CD,
same CD player. The difference was very audible, and a lot of it to me
was crispness in the upper frequency range. This CD player upsamples the
CD data to 192/24. So, to be sure the interpolation algorithms weren't
screwing with the CD audio, I played it in a regular CD player, and it
sounded worse than the upsampled version. My research indicated that
clock jitter is the number one cause of problems. This is why there are
$1000 CD players that do sound different, and their specs usually talk
about the jitter.

Jitter is a serious problem in stereo equipment. Ever listened to the
difference between the coax spdif and the TOSlink (from toshiba) on a
standard stereo? Regular cheap ($300+) stereos do not resync the digital
data coming down the light pipe. Because of this, the digital data in the
TOSlink, by circuit design and the cheap plastic fiber, has clock jitter
and modal distortion. This changes the digital pulses and affects the D2A
which is built on the principle of a stable clock (because of the
filters). I was reading about this problem on a stereo audiophile list
and didn't believe them. So I went and tryed both connections with my
stereo and I was shocked. In most expensive equipment, the digital data
coming in is reclocked so that problem doesn't exist.

> 'Quantization noise' -- but the key is 'can you perceive it' -- otherwise the
> typical high quality video (I'm thinking DV or DVCAM here) wouldn't already
> be compressed with a lossy algorithm. You cannot see the loss of quality
> unless you try to capture a still -- and then you wonder why there's all that
> pixelation in the 'digital' still. I've done that -- I thought copying from
> S-VHS to DV (on a Sony dual-well DV/S-VHS machine), then bringing it over to
> my notebook on FireWire would give me great stills. I got better stills
> using an analog vidcap card on a much slower PC than with the DV-> Firewire
> transfer.

Where this does become perceivable is when you are performing many
transforms to an image. Like effects. I mean it was pretty clear to me
when I was doing some image work, I discovered using larger files by my
own experiments. It's usually pretty easy to duplicate.

> The biggest thing about low latency for me is the issue of track-syncing
> during multitrack punch-ins. But even that can be worked around -- CoolEdit
> Pro does it with a latency compensation constant. Which really means that as
> long as the latency isn't too long and it is relatively constant it really
> doesn't matter -- I've done punchins with CEP on relatively high latency
> hardware that were perfectly synced by CEP's built-in latency compensator.
>
> However, everyone has a high latency processor anyway, between their ears.
> The brain's latency has been measured before, and it is substantial fractions
> of a second. But the brain has built-in compensators for its own latency --
> and any good musician who 'feels' the instrument can readily adjust to any
> latency by their brain applying its own already time-tested latency
> compensators. Between the time the brain tells the finger to pluck the
> string and the time the string is plucked is also measured in substantial
> fractions of a second. But musicans already adjust to this.
>
> There's a known 3/4 second delay between the eye receiving an image and the
> brain processing the image (which is pretty hefty horsepower, in reality).
> This is why all driving schools suggest three second following distances, to
> allow for the brain's latency (seeing the car's brake lights, understanding
> what that means, activating your own brakes, the latency of the brakes being
> applied and you stopping. And people are worried about the turn-on latency
> of incandescent lamps versus LED's -- it probably makes little real
> difference, but it looks good on papaer).
>
> Performers in an orchestra or band automatically and without much thought
> compensate for their own delays and latencies, including the one between the
> conductor's baton hitting the beat and their own brain seeing the conductor's
> baton hitting the beat.
>
> Yet no one is really aware of this high latency, because it is normally below
> the level of consciousness. I have actually experimented myself, just now,
> in trying to perceive the delay between thinking the word I'm going to type
> and seeing the word typed on screen. It is quite long, relative to the ms
> latencies we're talking about.
>
> In short, your brain doesn't have to be aware of it if it doesn't want to.
>
> Yet, there are other benfits of low latency.

True, I don't do live sound through my computer, in those cases as long
as the software can compensate for the latency when I playback and record
at the same time (which most do) then there is no issue. When I was
trying to use my computer as a live effects processor, that is when I was
having issues.

Rick

> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>

+------------------------+-----------------------+
| T a l i t y | +------+ |
+------------------------+ +----+-+ | |
| Richard Burnett | +-+ | |
| Senior Design Engineer +---+ +----+ |
| burnett_AT_tality.com | | |
| | | |
| Phone: 919.380.3014 | |
| Fax: 919.380.3903 | | |
+------------------------------------------------+


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

This archive was generated by hypermail 2b28 : Fri Jun 14 2002 - 20:51:27 EEST