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
