[Torq]

Thanks for the offer to try a couple of your cables, and thanks for the insights into the details about optical cables.

I remember that some early optical cables used to use a liquid as a 'bridge' between ends of the cable and the receiver to ensure 'proper' transfer of the data.
In fact I think it was Theta (Mike Moffet's former company) that used proprietary optical connectors with a special 'goo' at each end just to ensure a proper transfer of the data.

It would be an interesting experiment to see if the Lifatec cable makes a difference and if the changes would be enough to elevate the SQ to be 'Better' than my USB data path.

JJ

I remember, I think, the AT&T ST optical connections - not sure about a proprietary one. I don't recall the "goo", but I would assume it was an index matching medium. Something like the oil we use in high magnification optical microscopy to match the numerical aperture of the objective lens with the subject slide.

 

[johnjen]

Yeah now that you mention it, that was what the buzz at the time mentioned.
Sorta like impedance matching where reducing the number of interfaces (optical dispersion shifts) the light passed thru was the goal.

And its kinda funny that with optical the smaller the wire size (up to a point) the better, whereas with metal wires the reverse is true.

Just one of those 'makes ya wonder, don't it' situations. :atsmile:

JJ

 

[gefski]

So as an experiment I re-connected my optical cable back into my Mac Pro (pre Vader trash can model) and PWD.

After figuring out which inputs/outputs to configure I can switch back and forth with less than a 1 minute delay.

My usb is still 'Better' in terms of SQ.
It's not a HUGE difference but once again I heard tube like coloration shifts, which is surprising, yet again.
There were no drop outs or timing issues so I'm assuming that a 'better' optical cable won't make much if any audible difference, but I could be wrong about that.

I found the Lifatec cable and it certainly seems like a 'audio grade' piece of gear.
And reasonably priced at that.
Perhaps it might 'help' raise the bar for toslink, but I figure optical is much less susceptible to cable differences than any electrical data type path.
So, unless your experience supports a SQ shift with this cable I figure, for whatever reason my existing USB implementation is still gunna be 'Better'.

JJ

Those Lifatec cables with normal Toslink on one end and mac on the other look good.

But my recent trials with a mac adaptor and either good Wireworld glass fiber or basic plastic toslink from iMac to Yggy had me running back to usb. Not f/r differences, but a HUGE failing in timbre, bloom, vitality, flow of music. In other words, my whole reason for Yggy.

Fiddling with toslink, usb, spdif back when I had Windows, Bifrost, Benchmark etc. seemed to make little difference.

IMOYMMV in my current system only.

 

[Torq]

Those Lifatec cables with normal Toslink on one end and mac on the other look good.

But my recent trials with a mac adaptor and either good Wireworld glass fiber or basic plastic toslink from iMac to Yggy had me running back to usb. Not f/r differences, but a HUGE failing in timbre, bloom, vitality, flow of music. In other words, my whole reason for Yggy.

Fiddling with toslink, usb, spdif back when I had Windows, Bifrost, Benchmark etc. seemed to make little difference.

IMOYMMV in my current system only.

 
If you're talking about a TOSLINK to mini-TOSLINK adaptor when you mention the "mac adaptor", then I'm not at all surprised that things got off kilter.  That puts an additional glass/air interface in the way and can have fiber alignment problems on top of that.  Due to the design of the TOSLINK "connector", the same problem doesn't using an adaptor to go from mini to full-size.
 
Not to say that was necessarily the cause of the the issue, but I'd be surprised if it wasn't.

 

[bosiemoncrieff]

how much of a difference does Wyrd make?

 

[gefski]

If you're talking about a TOSLINK to mini-TOSLINK adaptor when you mention the "mac adaptor", then I'm not at all surprised that things got off kilter.  That puts an additional glass/air interface in the way and can have fiber alignment problems on top of that.  Due to the design of the TOSLINK "connector", the same problem doesn't using an adaptor to go from mini to full-size.

Not to say that was necessarily the cause of the the issue, but I'd be surprised if it wasn't.

So this Lifatec



...will be better than this adaptor plus a toslink cable.


I wouldn't be surprised at that.

I'm so happy with Yggy via usb that I won't spend much for further testing of toslink. Being retired, I'll just wait for the testing by you guys with significant disposable income.

 

[Torq]

So this Lifatec



...will be better than this adaptor plus a toslink cable.


I wouldn't be surprised at that.

I'm so happy with Yggy via usb that I won't spend much for further testing of toslink. Being retired, I'll just wait for the testing by you guys with significant disposable income.

 
Yes, definitely ... junctions in optical connections are a bad thing (much more so than with electrical connections).
 
It's worth noting that different Mac models have different optical emitters, so that can impact potential results as well.
 
As I offered to @johnjen, if you want to try one of my cables you're welcome too.  I'm finding even better results streaming via Ethernet to an Aries and coming of that via AES/EBU than I got with optical, so that's likely to become my long term interface choice.  But that doesn't work when it comes to using Audivarna or any of the EQ/Sonarworks plug-ins I've been experimenting with - so it's still optical for those.
 
I've started playing with USB for other purposes ... such as my smaller bed-side rig.  My, so far cursory, testing has shown definite benefits to things like Wyrd, Regen and Recovery feeding my Stockholm 2, but any benefits are far less clear feeding my Yggdrasil.  And coming off the USB port on the Aries they don't seem to add much value either.  But that testing is very early and I have more sophisticated DDCs I want to put in that chain before I draw any proper conclusions.

 

[artur9]

  how much of a difference does Wyrd make?

I used one between an iBook and a Wyred4Sound uLink to UberFrost.  Got rid of a noticeable amount of a sizzle-ly sound/noise.

 

[johnjen]

how much of a difference does Wyrd make?

By way of example…
I was using ethernet to send the digital stream from my mac to my Dac.
It was easily superior in SQ in multiple ways.

Until I did 3 things.
#1 The Wyrd
#2 audioquest coffee usb
#3 cooked the usb cables

After that the usb had surpassed ethernet.

The differences were much like tube coloration which surprised me.

And I've also used a 2nd Wyrd in series and it too also helps.
And since they are only $100 I'm about to get a second Wyrd for my data path.

Once I get it settled down (left on and used for a sufficient amount of time) I'll perform an evaluation.

JJ

 

[johnjen]

So this Lifatec



...will be better than this adaptor plus a toslink cable.


I wouldn't be surprised at that.

I'm so happy with Yggy via usb that I won't spend much for further testing of toslink. Being retired, I'll just wait for the testing by you guys with significant disposable income.

I've got two of those adapters…
They never worked so I gave up and went with the standard TOSLINK connectors which worked.
It might have been that I was plugged into the wrong socket, but I figured simpler was better anyway.

So, if memory serves, the iMac only has the miniplug for optical out, which means that Lifatec terminated with the minplug would be your best shot.

But then the 'try before you buy' option, thanks to Torq would be better yet since you'll find out if the Lifatec cable is up to the level of your current usb setup,
or not.

JJ :atsmile:

 

[landroni]

  Yes, definitely ... junctions in optical connections are a bad thing (much more so than with electrical connections).

 
It's worth noting that different Mac models have different optical emitters, so that can impact potential results as well.
 

Kind of puts a snag on the whole "bits are bits" theory. If you listen to some quarters, there should be NO perceived differences between the various transports in the digital world (USB, Coax, Optical, Ethernet, Wifi, etc.). But it seems quite clear to me that just like in the analog world, implementation details matter quite a bit.
 
So when you say that junctions are a bad thing in digital transports, what happens to the transported bits? Do bits get lost... err... in translation? Is the loss quantifiable, say as a percentage of total data, and do lost bits get automatically replaced by input receivers with 0s? And can the perceived differences be explained by the bits absent in real-time streaming?
 
I'm wondering because these things seem like easy to test with access to the right equipment, checking input data with packages received at each point in the chain at each point in time... I mean, if the "bits are bits" hypothesis doesn't hold in real-time streaming, there has to be a mechanism for differing perceived differences from something that nominally should unmistakenly be 0s and 1s.

 

[macon]

My Mid-2010 iMac uses the 3.5mm headphone output with the integrated optical connection. I agree with one piece is preferable.  This is my preference vs USB 2.0. There are many affordable Spdif TOS to 3.5 mm on Amazon or Ebay. So far I have not compared any two optical cables. 
 

 
I ordered my Mjolinir-2 Feb 23rd - I've recieved 3 boxes of Bolivar cigars from Geneva already!! (No complaints, they warned me and I gladly accepted late March) so my Lyr-2 looks like a metal dwarf. I am foaming at the mouth to begin to compare my final choice for amplifiers...the Yggy is the single best piece of 'head fi' i've ever purchased.
 
It was like seeing the MBL speakers in the living room for my hifi the first time (and they replaced Wilson Grand Slam speakers)... 
 
 


I dig this Schiit. I'm not necessarily going to pass on Jam's Pass either. 

 

[Torq]

Kind of puts a snag on the whole "bits are bits" theory. If you listen to some quarters, there should be NO perceived differences between the various transports in the digital world (USB, Coax, Optical, Ethernet, Wifi, etc.). But it seems quite clear to me that just like in the analog world, implementation details matter quite a bit.

So when you say that junctions are a bad thing in digital transports, what happens to the transported bits? Do bits get lost... err... in translation? Is the loss quantifiable, say as a percentage of total data, and do lost bits get automatically replaced by input receivers with 0s? And can the perceived differences be explained by the bits absent in real-time streaming?

I'm wondering because these things seem like easy to test with access to the right equipment, checking input data with packages received at each point in the chain at each point in time... I mean, if the "bits are bits" hypothesis doesn't hold in real-time streaming, there has to be a mechanism for differing perceived differences from something that nominally should unmistakenly be 0s and 1s.

Let's start super-simply and take the specific interface out of the equation:

Even if you get all the right bits, properly clocked, to your destination, which isn't hard to do with an error detecting/correcting (or retransmitting) scheme*, the noise inherent to, and generated by, all electrical circuits can affect the conversion of that data into the analog signal necessary to output an audio wave form.

Since all electrical circuits have different noise characteristics, they can have different effects on that analog signal. Those can be audible, especially when they occur during DA conversion and/or before amplification.

The bits remained bits, the clock remained "perfect", and yet still there are different possible effects on the output.

That's not a concern (or when it is, it is easily dealt with) for all-digital systems such as computers transferring files, since we don't have to deal with the analog conversion.

...

Now, when it comes to actually transmitting the data:

With fiber optic systems every junction between two different transmission mediums causes additional attenuation. So going from glass to air and then back to glass, as you do with those little adapters, reduces the number of photons that make it from emitter to the receiver.

The receiver is generally a photodiode. Those change their electrical resistance or generate a potential difference when illuminated, depending on the precise type of diode and how is is applied. This effect is dependent on photons reaching, and being absorbed, at the depletion region of the diode. If insufficient photons reach that point then the change in conductivity or the current generated may be below the detection threshold for the receiving circuit.

That results in a "1" registering as a "0".

It can also make edge detection on the bi-phase clock unreliable which causes jitter issues.

(Make that circuit too sensitive and it can register a "1" spuriously.)

There are various ways to deal with this, and nothing stops you using an error detecting/correcting protocol but, in audio, the most common existing standards don't*!

What effect this has, when it occurs, depends entirely on the decisions made by the system designer. In general, however, since we don't know what we were SUPPOSED to receive, the result is either clock error or outputting the "wrong" voltage. Whether you can hear that or not depends on many factors (frequency and magnitude of error, for example).

...

Now, suppose you eliminate these interfaces entirely and play from a source directly housed in your conversion device. That might be a memory card, a RAM buffer (those are pretty much ALWAYS the final source) or a spinning disc ...

Guess what?

While you've eliminated the VISIBLE digital interface, there is still one present, and the eventual analog output is still potentially affected by any noise it generates. Which is one major reason why DACs got externalized from the transports/players in the first place!

...

Yes it's entirely possible to build a device that captures the incoming bit stream and writes it to a file so you can compare it to the source. That'll tell you that you did or didn't get the data (and it was timed) you were intended too. That will tell you absolutely NOTHING about what happens post-reception as that digital data is converted to analog however.

--

*S/PDIF (and AES3 on which it is based) whether electrically or optically transmitted, and USB Audio do not have error detection/correction/retransmission capabilities. So you have no way to guarantee accurate data delivery.

HDMI Audio does include ECC (error correction code) data in the stream and thus CAN be reliably reconstructed by the receiver even after transmission errors (provided the number of errors is less than the number of correctable bits provided for in the ECC). However, this does NOT prevent the same downstream noise effects from affecting the converted analog signals (or, indeed the analog conversion process).

(Please excuse any typos or incomplete thoughts ... picking away at this on my tablet while doing several things at once .. )

 

[Torq]

I should add ... or clarify ...

Even when you get the same, properly delivered and timed, data from all interfaces (TOSLINK, COAX, AES/EBU or USB), since each interface requires a different electronic implementation they will all have different noise characteristics which will have different potential effects on the downstream DA conversion and analog output circuits.

So ... differences between transmission options can still result in audible differences even when there is NO difference in the data they deliver.

In other words ... they can result in a different sound even with perfect bits-are-bits delivery.

 

[earnmyturns]

  I'm wondering because these things seem like easy to test with access to the right equipment, checking input data with packages received at each point in the chain at each point in time... I mean, if the "bits are bits" hypothesis doesn't hold in real-time streaming, there has to be a mechanism for differing perceived differences from something that nominally should unmistakenly be 0s and 1s.

Update: saw that Torq explained many of of the same points, with more detail, while I was writing this, but I'll leave it here in case the two different ways of explaining may complement each other.
---------
I'm not an electrical engineer (actually, started school as one but turned into mathematician and then computer scientist), so season with pinch or even bucket of salt, but I'll try to explain the confusion behind "bits are bits". TL; DR: bits are bits (modulo disasters) if all you want to do with them is to transmit and store them as bits.
 
Bits in transit are represented by electromagnetic waves (whether as electrical currents or light). For purely digital transmission and storage purposes, "bits are bits" in the sense that if the waveforms are not totally mangled, and possibly with the help of error-correction codes, it is possible for the receiver to replicate the bits sent exactly (Shannon is your friend). However, when the bit-encoding waveforms are streaming into a DAC, another factor intervenes: timing. Accurate D2A depends on many factors, some discussed to exhaustion here in the d-s vs multibit + exact filter, but one of them is when the bits encoding a sample actually trigger a change in the analog waveform out of the DAC. These changes should be clocked very precisely to match the clock in the original digital encoding process. If that matching is off or varies in time, timing errors lead to analog waveform reconstruction errors, thus analog distortion. Bit-encoding waveforms in incoming digital stream get distorted from their theoretically nice sharp on-offs by various mechanisms of frequency-dependent transmission speed and attenuation (depending on the exact properties of the transmission medium), so at the receiving (DAC) end there's a real challenge in deciding when *exactly* that bit has arrived (for a beautiful piece of theory on why this cannot be done without compromises: http://research.microsoft.com/en-us/um/people/lamport/pubs/buridan.pdf). So, a lot of the struggle is to replace the timing noise -- jitter -- from the transmission of the incoming digital signal by a much cleaner clock signal that places the bits at very accurate positions in time to drive the r2r ladder accurately. In theory, one could just have a very large incoming buffer in the digital domain and then push the bits out to the r2r ladder with a super-accurate clock. But there's no free lunch. Buffering costs, it makes user control of play-no play laggy, and like any other complex digital circuitry it can inject high-frequency analog noise into the downstream analog components. High-frequency analog noise also leaks from the high-frequency components of the bit-encoding waveform, from switching power supplies commonly used in digital gear, and from lots of other sources. Since a DAC is by construction a nonlinear device (in the sense of signal theory), those high-frequency components can get aliased into the audible range, for more analog distortion.