Archimago;401824 Wrote:
> Curious why BNC is the best solution.
Because it's a properly designed RF connector with a 75 Ohm
characteristic impedance to correctly match the 75 Ohm characteristic
impedance of the link.
--
Patrick Dixon
www.at-tunes.co.uk
---
Looked for awhile and couldn't find the message you're referring to ar-t
on Audio Circle. Would love to read it if you can find a link to it.
Curious why BNC is the best solution.
--
Archimago
Archimago's Profile: http:/
I consider BNC to be the only option, period.
If you go over to Audio Circle, in The Lab area, I posted some results
of various commonly used attempts to wire SPDIF. Don't have a link, but
I assume their search feature works. (User name there is "art",
different from the one I use here.) Posted o
Is BNC the only studio-grade option?
--
NewBuyer
NewBuyer's Profile: http://forums.slimdevices.com/member.php?userid=7862
View this thread: http://forums.slimdevices.com/showthread.php?t=50147
It is! I talked to the guy who headed up the AES working group on that.
Of course, this was after they printed it in the JAES. I explained to
him all the problems that I saw with it. I could sense his feeling was
"Gee, why didn't we get someone like this guy to help us out. I had no
idea about any
ar-t;398224 Wrote:
>
> -It is only consumer grade audio.- Not studio grade. We should consider
> ourselves lucky that it became 44.1 kHz.
ironically, AES/EBU is even worse...
--
seanadams
seanadams's Profile: http://for
seanadams;396050 Wrote:
> Anyway the point is, the designers of s/pdif didn't deliberately choose
> a "sub optimal" scheme. Maybe they were unaware of the problem of
> jitter (I could believe that actually) but just as easily they could
> have considered it and made a decision that it was outweig
TiredLegs;396321 Wrote:
> I find it ridiculous myself, for reasons such as the cumbersome HDCP
> handshake, the flimsy physical connector, etc.
Yes, yes. Also the DRM nonsense, the fact that you have to pay a
royalty to use it, etc. It is DVI plus a big steaming pile of "do not
want".
--
se
seanadams;396050 Wrote:
> If you're willing to overlook clock noise then the unidirectional,
> single conductor that comprises s/pdif is really quite elegant, and
> makes it both easy to use and inexpensive to implement. You will never
> see word clock connections on mass market equipment because
TiredLegs;395965 Wrote:
> Sean,
>
> Thanks for the explanation to someone (me) who doesn't know what he's
> talking about when it comes to the inner workings of these devices. It
> just seems bizarre to me that the bulk of this thread discussion is
> about handling extremely minute variations in
Sean,
Thanks for the explanation to someone (me) who doesn't know what he's
talking about when it comes to the inner workings of these devices. It
just seems bizarre to me that the bulk of this thread discussion is
about handling extremely minute variations in the timing of data
delivery for less
TiredLegs;395799 Wrote:
> I'm not an electronics guy, so maybe I'm missing something. These days,
> RAM is dirt cheap, so why don't DAC makers just add a gigabyte or two
> of memory buffer, and not have to worry about emptying or overflowing
> the "bucket" as they reclock the data on the way out?
I'm not an electronics guy, so maybe I'm missing something. These days,
RAM is dirt cheap, so why don't DAC makers just add a gigabyte or two
of memory buffer, and not have to worry about emptying or overflowing
the "bucket" as they reclock the data on the way out? As long as the
buffer is large e
DCtoDaylight;332578 Wrote:
> So what we really need then is a way to quantify the jitter type, rather
> than the overly simplistic RMS Jitter value usually quoted in spec
> sheets. Another case of the graphical representation giving you a lot
> more information than a simple number. As long as
JohnSwenson;332480 Wrote:
> This agrees with a lot of other measurements, that broadband noisy
> jitter is less detrimental than high amplitude narrow spikes.
So what we really need then is a way to quantify the jitter type,
rather than the overly simplistic RMS Jitter value usually quoted in
s
DCtoDaylight;332327 Wrote:
>
>
> I would expect that we would find that the audibility of jitter depends
> on both the amplitude and the type. We could probably tolerate much
> higher levels of totally random jitter, than a single fixed frequency
> peak.
>
>
This does seem to be true. I'v
Phil Leigh;332298 Wrote:
> If jitter really worked like that you could inject controlled, simulated
> jitter into a replay chain and see what happened to the sound...but it's
> not that simple. Jitter is a variation in the clocking mechanism, not a
> discrete analogue artifact in its own right.
opaqueice;332306 Wrote:
> As long as we're talking about jitter at the clock that controls the DAC
> chip proper, it really is that simple. You can read various white
> papers on the web about it, or just draw a picture and you'll see why
> it's true. It's essentially because the timing variati
Phil Leigh;332298 Wrote:
> Hmmm...
>
> If jitter really worked like that you could inject controlled,
> simulated jitter into a replay chain and see what happened to the
> sound...but it's not that simple.
As long as we're talking about jitter at the clock that controls the
DAC chip proper, it
Phil Leigh;332298 Wrote:
> Hmmm...
>
> You (SartoriGFX) may have found that the CI DAC works really well with
> the CEC transport compared to the SB.
If the DAC is what makes the difference than any transport should do.
Certainly, the DAC defines the basic sonic signature, but if transports
do
Hmmm...
If jitter really worked like that you could inject controlled,
simulated jitter into a replay chain and see what happened to the
sound...but it's not that simple. Jitter is a variation in the clocking
mechanism, not a discrete analogue artifact in its own right.
My experience with a whol
If the jitter spectrum is peaked at some frequency, its effect is to add
anharmonic sidebands at that frequency. In other words, if you have a
1kHz signal with 100 Hz jitter, the resulting analog signal will have a
big peak at 1kHz (the signal) plus smaller peaks at 900 and 1100 Hz (the
distortio
TiredLegs;332273 Wrote:
> What exactly does digital jitter sound like after its converted to
> analog?
Apparently, that depends on the amount of jitter and at what frequency
that jitter occurs (jitter is apparently not the same at all
frequencies).
If I am to believe that jitter is the only thi
TiredLegs;332273 Wrote:
> What exactly does digital jitter sound like after its converted to
> analog?
I was wondering when someone was going to ask that :o)
IME a lot of jitter sounds like a headache...or at least you don't want
to listen for very long. It certainly doesn't translate for me in
SatoriGFX;331654 Wrote:
> And yet the jitter present on the digital outputs of the Squeezebox is
> still higher than several traditional transports and is quite audible
> when feeding an external DAC.
What exactly does digital jitter sound like after its converted to
analog?
--
TiredLegs
-
SatoriGFX;331735 Wrote:
> With the CEC I get more transparency, more detail, more air around
> instruments/singers, more flesh/body to instruments/singers, more
> natural tone to instruments, more extension at the extremes etc... The
> SB3 doesn't sound bad but after hearing the CEC I can't dism
opaqueice;331739 Wrote:
> By the way, the SB3 jitter is -not- high, at least according to various
> measurements I've seen. IIRC it's somewhere below the 100ps mark. I
> think most digital transports have considerably higher jitter.
Sure, the SB3 has lower jitter than some/many more expensive
opaqueice;331736 Wrote:
> Hmm. You might want to try out a more "hi-tech" dac and see if it
> helps.
>
>
>
> Really? Why do you say so? My impression was the opposite, but then
> the only hard data I've seen is supplied by the manufacturers, a few
> not very reliable reviewers, and some (po
It's not just the magnitude of the jitter that's important, it's also
the spectral content and its correlation with the audio signal.
I agree with opaqueice though, the re-clocker just seems like it's
adding extra complexity where you'd be better off tackling the
'problem' at source.
--
Patric
SatoriGFX;331735 Wrote:
> I do believe that the higher jitter of the SB3 is responsible.
By the way, the SB3 jitter is -not- high, at least according to various
measurements I've seen. IIRC it's somewhere below the 100ps mark. I
think most digital transports have considerably higher jitter.
SatoriGFX;331734 Wrote:
> I am using a CIAudio VDA-2 NOS DAC. No jitter reduction scheme.
Hmm. You might want to try out a more "hi-tech" dac and see if it
helps.
> The Benchmarks jitter reduction claims are apparently somewhat
> overstated. The Lavry is apparently better at it.
Really?
Phil Leigh;331732 Wrote:
> Can you quantify this difference in audible terms? - how does it
> manifest itself?
With the CEC I get more transparency, more detail, more air around
instruments/singers, more flesh/body to instruments/singers, more
natural tone to instruments, more extension at the e
opaqueice;331731 Wrote:
> What dac are you using?
>
> Benchmark's are claimed to be immune to input jitter. Also, the Lavry
> dacs were supposed to use a technique similar to the one I described
> above (a buffer plus a clock with an adjustable frequency), but there
> was some dispute over wh
SatoriGFX;331728 Wrote:
> I see your point. I guess I misunderstood where you were coming from.
> I assumed you were claiming the SB3 had inaudible jitter on it's
> digital outputs. How I wish it were so. I love my SB3 but it's
> digital outs sound inferior to those on my CEC transport, I ass
SatoriGFX;331728 Wrote:
> I see your point. I guess I misunderstood where you were coming from.
> I assumed you were claiming the SB3 had inaudible jitter on it's
> digital outputs. How I wish it were so. I love my SB3 but it's
> digital outs sound inferior to those on my CEC transport, I ass
opaqueice;331723 Wrote:
> You didn't understand the point.
>
> I wasn't claiming there is anything inherently superior about the SB
> architecture as a -transport-. You want the lowest possible jitter at
> the dac (because that's the only place it makes any difference at all).
> It's useless to
SatoriGFX;331654 Wrote:
> And yet the jitter present on the digital outputs of the Squeezebox is
> still higher than several traditional transports and is quite audible
> when feeding an external DAC.
You didn't understand the point.
I wasn't claiming there is anything inherently superior about
opaqueice;331646 Wrote:
>
>
> There's a device you might of heard of that uses that second trick.
> It's called a "squeezebox".
And yet the jitter present on the digital outputs of the Squeezebox is
still higher than several traditional transports and is quite audible
when feeding an external
firedog;331405 Wrote:
> As per the discussion quoted below, is this what the
> http://www.empiricalaudio.com/frPace-Car.html Pace Car device does.
>
Sounds like it, yeah. But frankly I don't see the point. Even if you
can get rid of the input jitter, you're going to inject more again in
the
Patrick Dixon;325317 Wrote:
> My own take on these things is that life is complicated enough as it is,
> and using complicated solutions to solve problems that you don't need to
> have in the first place, is generally a bad idea. As ever, YMMV!
In principle, I couldn't agree more!
Darren
--
d
As per the discussion quoted below, is this what the
http://www.empiricalaudio.com/frPace-Car.html Pace Car device does.
Some pretty big claims are made for its effect on sound.
Thanks
opaqueice;325172 Wrote:
> Consider the following scenario: suppose you have a local clock in your
> DAC with
DCtoDaylight;326085 Wrote:
> Sorry, I intended to reply to this, but got side tracked... It works
> because the SRC doesn't need to rely on the received clock signal to
> know the timing. It knows that the incoming sample rate is 44.1k (or
> 48k or whatever), and it computes the new data based o
Sorry, I intended to reply to this, but got side tracked...
NewBuyer;325130 Wrote:
> If the digital datastream is mis-timed upon receipt due to sending-clock
> and/or transmission-interface jitter, this mis-timed data will of course
> be received as such at the next device, and merely be re-enco
Dave (DC),
Shall I assume then, that you choose not to reply to my above post
addressed to you?
If so, no worries - perhaps it contained "dumb questions", which
unfortunately wouldn't be the first time for me :)
--
NewBuyer
-
Patrick Dixon;325317 Wrote:
> Yes, you're right. But I suspect that making the small frequency
> adjustments to the read clock in such a way as not to compromise it's
> overall performance is not all that easy. You might like to try and
> build one and see how it works!
But if you think about
opaqueice;325172 Wrote:
> Consider the following scenario: suppose you have a local clock in your
> DAC with an adjustable frequency (such clocks exist and are used in some
> DACs). For simplicity we'll ignore jitter in that clock (and any other
> local jitter source) and worry only about jitte
Patrick Dixon;325171 Wrote:
> Solving the problem with a buffer is not straightforward. The read and
> write clocks will never be at exactly the same frequency (and won't be
> constant either), but they are at the same nominal frequency.
Consider the following scenario: suppose you have a lo
DCtoDaylight;325102 Wrote:
>
> A problem -can- arise, if the two clocks are not at exactly the same
> frequency. As you might guess, if the buffer in the interface isn't
> large enough, you could overflow or underflow it. As a result you
> either need a large buffer (which has been done, memor
DCtoDaylight;325080 Wrote:
> Ok, you got me on a technicality! You are 100% correct, jitter in the
> Analog to Digital converter does imprint itself on the data. And in
> the same context, you could say jitter in the Digital to Analog
> converter is also imprinting itself on the audio stream.
DCtoDaylight;325102 Wrote:
> ...Again, an asynchronous interface will only use the received clock for
> receiving the data. It's jitter is of no concern, and will never harm
> the output...
DC, if you are willing, please feel free to educate me here. :)
My questions: If the digital datastream
occam;325048 Wrote:
> But with asychcronous reclocking you certainly embed it from the analog
> domain of jitter within the digital signal. Simply consider a
> asychronous reclocking from nominal 44.1kHz to the same 44.1kHz. Unless
> both the input clock and reclocking are jitter free as well as
Patrick Dixon;324980 Wrote:
> It does if the data is a PCM representation of an analogue signal and
> you are in the process of converting it between the analogue and
> digital domains.
Ok, you got me on a technicality! You are 100% correct, jitter in the
Analog to Digital converter does imprin
DCtoDaylight;324918 Wrote:
> I'm afraid you don't understand what jitter is...
> Jitter is variation on the timing of one sample to the next. You can't
> remap jitter, it has no effect on the data (unless it's so grossly large
> that it causes read errors, not the case here).
>
> Most sample ra
DCtoDaylight;324918 Wrote:
> [jitter] has no effect on the data (unless it's so grossly large that
> it causes read errors, not the case here).
> It does if the data is a PCM representation of an analogue signal and
you are in the process of converting it between the analogue and
digital domains
Nonreality;322895 Wrote:
> This is just typical crap to leave the shadow of doubt in your mind that
> you might be missing something although if it is missing you would have
> to have audiophile ears to hear it. That way if you don't hear a
> difference it's because you don't have the qualificat
Look at the jitter test charts published right in the user manual for
the Benchmark DAC1 Pre
(http://www.benchmarkmedia.com/manuals/DAC1-PRE_Manual_RevD.pdf). It
shows tests with up to 2075 nanoseconds of jitter, way way way more
than you'd encounter in any device that isn't broken. (For digital
a
gsawdy;322913 Wrote:
>
> I seem to recall that two of the things that were important in the
> development of the Transporter were jitter and power supply. (Could be
> wrong/forgetful here.)
The keyword there is development. Transporter was designed/developed to
have critical stages powered by
I've come across this discussion of jitter as caused by power supply
deficiencies.
http://www.geocities.com/jonrisch/jitter.htm
I seem to recall that two of the things that were important in the
development of the Transporter were jitter and power supply. (Could be
wrong/forgetful here.)
Sin
"What really set the Bolder Duet apart from the stock Duet was its
analog performance. I must clarify this statement by noting the digital
output through a good DAC is far better than the analog output. But the
difference between the stock and modded Duet is less pronounced when
listening via the
opaqueice;322841 Wrote:
> If there was a real audible effect (which I very much doubt), jitter is
> the most obvious guess (although the Benchmark is supposed to be
> totally immune to it).
>
> But there are other possibilities - if the Duet was connected via a
> coax cable, it might be pickin
gsawdy;322154 Wrote:
>
> "...difference between the stock and modded Duet is less pronounced
> when listening via the digital outputs..." Is this possible? If the
> digital outputs are bit perfect from both the stock and modded then
> they should sound the same via the Benchmark external DAC.
Hi K,
I was going to look up my old messages and tell you that I found a pair
of new, but original version Powerpoints for the kitchen. Was able to
save some $. They are black, so I'll have to paint them but do they
ever sound good---beats the pants off down firing ceiling speakers.
Let's se
gsawdy;322154 Wrote:
> Can folks on this board explain how this review's claim about the
> digital out of a modded and non-modded Duet be true. Here is a link to
> the review:
> http://www.computeraudiophile.com/bolder_cable_company_squeezebox_duet_review
>
> The parts that I find puzzeling are
CatBus;322164 Wrote:
> I think you just answered your own question here. The only way it could
> have a basis in theory is if it could stand the test of DBT. If you
> doubt one, then you doubt the other.
>
> It's much more useful to verify the observed phenomena than to develop
> a theory to e
gsawdy;322154 Wrote:
>
>
> "...difference between the stock and modded Duet is less pronounced
> when listening via the digital outputs..." ...
>
this just means the reviewer could not hear damn bit of difference, but
is reluctant to say so.
K
--
slimkid
Where does the light go when you
gsawdy;322154 Wrote:
> Of course one has to doubt any of this would stand the test of a DBT,
> but I am curious to know if there could be some basis in theory.
I think you just answered your own question here. The only way it
could have a basis in theory is if it could stand the test of DBT. I
Can folks on this board explain how this review's claim about the
digital out of a modded and non-modded Duet be true. Here is a link to
the review:
http://www.computeraudiophile.com/bolder_cable_company_squeezebox_duet_review
The parts that I find puzzeling are:
" I connected the stock SB Duet
67 matches
Mail list logo
