• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

DX7s doesn't work with Airport Express

Joined
May 17, 2018
Messages
3
Likes
0
#1
After reading the review on this forum, I purchased a DX7s. One caveat with this DAC: it doesn't work with an Apple Airport Express. Apple has basically abandoned this product line so this may matter less in the future but it was a disappointment for me. The symptoms are glitches/silences in the sound. The DX7s seems to have some pop protection and it sounds as if this is being invoked periodically.

The airport express worked well with my previous DAC (ironically, a schiit modi multibit). Since the DX7s w/ airport express was the first device I tested, I initially believed my DX7s to be faulty, but that does not appear to be the case.

Here are configurations I tested:

with a new Toslink to Mini-Toslink cable between the Airport Express/DX7s -- same problem
with a standard Toslink-Toslink and Mini Toslink adapter (different brand of cable) -- same problem
with another Airport express device (same model) -- same problem
with my television's optical output connected to the DX7s -- works fine
with a PS3's optical output connected to the DX7s -- works fine
believing that perhaps it was the 1/8" analog/mini toslink combo jack that Apple uses, I tested connecting a Macbook Pro with the same jack to the DX7s -- it worked fine
finally just to make sure there wasn't something wrong with both the Airport Express units, I tested them with both the Modi Multibit and a sound bar I own with optical input -- both worked fine.

Clearly, the problem is some kind of bizarre incompatibility between the Airport Express units and the Topping DX7s. I wrote to Topping asking them about it, this is what I got back:

We believe this is compatibility problems between DX7s and airport express. We had received report of this before and test airport express from our customer. Our test shows that signal of airport express is not standardized enough and it will often break and recover very quickly, which cause slow volume increase function of DX7s active, then the result is even successfully connect them, volume of DX7s will shut down suddenly and then slowly increase. Therefore, we do not recommend DX7s working with airport express.
Based on this, my best guess is that the DX7s' pop protection circuitry is a little too trigger-happy. I hope this helps anyone else considering buying this DAC.
 

gvl

Senior Member
Joined
Mar 16, 2018
Messages
488
Likes
134
Location
SoCal
#2
It appears that the DX7s can't deal with the jittery AE optical output. If you're determined to get this setup going an inline reclocker such as iFi SPDIF iPurifier or the older Monarchy Audio DIP may help. There are/were other reclockers too out there. It is an unplanned expense of course.
 
Joined
May 17, 2018
Messages
3
Likes
0
#3
While I agree with the poster who suggested SPDIF reconstruction using a memory buffer and a more accurate clock than the AE would probably fix the issue, it begs the question: If memory buffering and signal reconstruction can be done in an inline device, it can be done in the DAC itself, with the cost of a likely unnoticeable amount of latency. Why isn't this a standard feature of DACs to mitigate this problem?

Also, is it worth adding a device that costs twice as much as the AE itself to solve this problem, or might the money be better spent on a fanless HTPC running Airserver? A PC has the possible benefit of offering asynchronous USB, which effectively serves the same purpose as inline re-clocking/signal reconstruction, as well as being able to play higher resolution and DSD files from a media that i could perhaps remote control from my mobile -- might be a better solution than airplay. Does anyone know of something like this?
 

gvl

Senior Member
Joined
Mar 16, 2018
Messages
488
Likes
134
Location
SoCal
#4
This is not really about a memory buffer but rather if the SPDIF receiver can cope with out of spec devices and reliably lock onto jittery data streams, apparently the DX7s cannot. Technically the AE is at fault, but given the Schiit product works fine I would reluctantly point my finger towards Topping for not validating their DAC works with a popular device that is known to cause issues. IMO adding a reclocker isn't worth it unless one can be sourced used at a good price. Then again, the reclocker may have the same kind of issue but given it is a device that's supposed to be designed to work with jittery source it should be more tolerant. A reclocker will also have another benefit of reducing external jitter . Google Chromecast Audio performs a function similar to the AE, I, however, cannot comment how well it integrates with Apple products.
 

restorer-john

Addicted to Fun and Learning
Joined
Mar 1, 2018
Messages
687
Likes
661
Location
Gold Coast, Quuensland, Australia
#5
I would bet this could be solved with a simple circuit and 'reclocking' would be unnecessary.

It is likely nothing to do with jitter and simply a consistent pulse duty cycle error. It's a biphase signal and needs to be at a 50:50 duty cycle. Optical transmission distorts this.

Here is an example of a simple circuit used to great success in a high end D/A equipped amplifier from the late 1980s- it was well understood then.

optical 02.JPG

optical 01.JPG


optical 03.JPG
 
Joined
May 17, 2018
Messages
3
Likes
0
#7
My background is in computing, not in audio circuits, so I may be speaking out of turn, but it seems to me that Differential Manchester encoded signals like SPDIF, where the bit state is signalled only by the presence or absence of a phase transition at any point between clock transitions, not the signal polarity itself, would be insulated by design from inaccuracy due to duty cycle distortion, assuming the clock transitions were in close agreement at either end (no clock-based source of jitter).

Of course if this were combined with jitter caused by clock disagreement, these could be magnified by duty cycle distortion to cause more frequent misreads than would be present otherwise. So I would imagine in the case of SPDIF, clock jitter and duty cycle distortion ARE related phenomena. In any case, while it is quite clever and elegant to feed the phase difference back into the circuit to equalize it, and a simple way to deal with that one specific problem, it seems that today, using an IC that incorporates a small memory buffer and some kind of decoding enhancement like an oversampling decoder or maximum likelihood decoding provides a more generalizable form of clock recovery and signal reconstruction, which, as I mentioned, can either be present in an inline device like those being sold to reduce jitter (but of course these have the problem that unless their re-encoding scheme, clock and signal quality is better than the source, they may re-introduce more jitter, which may explain why they're so damn expensive) or (better yet) in the DAC IC in the receiving device itself. For fairly primitive signal coding like SPDIF that doesn’t contain any of the modern features of signal transmission like packets, retransmission, parity, CRC and other error corrections, this ‘basic’ form of digital reconstruction would seem ‘de rigeur’ considering how cheap ICs are these days.


Again, I speak with very little specific understanding of audio circuits per se, so if I’m missing a critical point feel free to correct me.
 
Last edited:

gvl

Senior Member
Joined
Mar 16, 2018
Messages
488
Likes
134
Location
SoCal
#8
High-quality SPDIF interfaces, e.g. WM8805, do have built-in jitter-correcting features. Anyone knows what DX7s uses on the SPDIF receiving end?
 

restorer-john

Addicted to Fun and Learning
Joined
Mar 1, 2018
Messages
687
Likes
661
Location
Gold Coast, Quuensland, Australia
#9
In any case, while it is quite clever and elegant to feed the phase difference back into the circuit to equalize it, and a simple way to deal with that one specific problem, it seems that today, using an IC that incorporates a small memory buffer and some kind of decoding enhancement like an oversampling decoder or maximum likelihood decoding provides a more generalizable form of clock recovery and signal reconstruction
I consider it also to be a very elegant and clever little circuit.

The digital filter circuitry in that particular unit uses integral data RAM, temporary RAM and overflow limiting and the data demodulator VLSI handles all synchronization and clock recovery. The duty-cycle correction circuitry was in addition to that. A similar optical distortion circuit was (pre) applied to the digital tape loop optical outs as well. Overkill maybe, but a superb implementation IMO.

I have played around with the above circuit and can attest to its effectiveness in a standalone breadboard situation, where I had poor locking to SPDIF streams from flat panel TVs to standalone HiFi D/A converters. I've only used it up to 48KHz and DD streams.

I have noticed that many AVRs are overly sensitive to optical streams and over the years, when selling audio, some simply wouldn't play together. In the early days of Toslink, the optical deficiencies were understood and corrected for, as time went on, it seems manufacturers left it all to the PLLs/Demod ICs to clean up and some worked better than others.
 
Top Bottom