Chris wrote:
[in an exchange with Paul Davis:]
>>This topic is likely to end in a flamewar in any
>>hi-fi related newsgroup, because it tends to be
>>based on a mixture of subjective perceptions along
>>with hard physical facts. My (honest) question would
>>be: Did you ever _hear_ the result of jitter?


> understanding) of signal theory.  The most common reported
> effect is high-frequency "graininess" or "harshness."  This
> seems to make sense considering that a sudden dropped
> sample in between two others could be seen as a
> high-frequency component of the signal. 

More like a localized discontinuity in the signal. I wouldn't describe 
it as "grainy". I would describe it as noisy, pure and simple. A very 
short pop. I've had enough off-by-one errors in audio code to be 
familiar with it. The results vary from subtle to unlistenable.

> A DAC with it's own clock but no buffer would be subject to
> clock drift between it and the source, thereby dropped and
> duplicate samples would occur.  I don't think anybody is
> dumb enough to do this.. (I hope)
> 
> A DAC with a buffer and it's own clock would eliminate the
> timing variation of the source, but its clock would have to
> intelligently sync to the average clock rate of the source
> and employ a large enough buffer to handle the expected
> variance of the source clock.  This would cost the most.

MPEG-2 transport streams have the same problem - the transmitter is 
physically distant from the receiver (say, by a round trip to a 
sattelite), and this is dealt with by the receiver locking its clock to 
the transmitter's clock (using a PLL). The buffering required by the 
MPEG systems spec is ridiciulously small, and MPEG-2 chipsets cost 
pennies nowadays, so I don't think it should cost too much.

> A system with a shared, low-jitter master clock would
> fairly ideal, but most equipment isn't designed for this
> and theoretically jitter could still be introduced by the
> transmission lines (ie. digital interconnects and other
> wiring or optical links).  Some buffering would still be
> desired, albeit a smaller amount to minimize latency.

That would be silly, in my opinion. Digital video equipment that does 
this has all sorts of interesting wiring failure modes that stereo 
equipment doesn't have, and the timing requirements can be met perfectly 
  well by embedding a clock sample in the bitstream, the way MPEG does it.

The only source of jitter I can think of is if the transmitter inserts 
clock samples that are incorrect, causing the receiver not to lock to 
it. Synthesizing an accurate clock sample when the bitrate is constant 
shouldn't be hard, though. Of course, I don't actually know whether 
S/PDIF transmits an embedded clock.


> I agree 100%.  Why try to time the signal at the source?
> But of course, as you mentioned, this was done due to the
> limited technology when digital audio began.  USB
> 'soundcards' are kinda interesting, though unfortunately
> 
> not supported by ALSA yet. ):

USB won't solve anything. A bitstream is a bitstream is a bitstream, and 
USB can only make things worse by sharing the bus with other devices. 
You'll always need buffering, unless you can implement flow control that 
can slow down your A/D converter when the receiver's bufer is about to 
overflow, or speeds it up if it is about to underflow, which would be a 
bad idea for audio.


>>>Well, the sb-live resamples everything internally
>>>to 48 KHz, even stuff from the S/PDIF, even if it's
>>>already at 48 KHz. So it's never a pure transmission.
>>>I believe many other cards do this too, but I don't
>>>know which ones.


> I will say that between the digital outs of the SB Live and
> the C-media 8738, the C-media card is remarkably clearer
> when playing at 44.1Khz. and I know for fact that it does
> no internal re-sampling.

The resampling can definitely mess up the sound.


-Ori Pessach


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_______________________________________________
Alsa-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-user

Reply via email to