MDAC First Listen (part XXVI)

[rmgalley]

Hi John,

Thanks for the update. I’ve been racking my brains trying to fathom out a mechanism for the impairment and am thankful you too hear the effect.

I am ashamed to say I hadn’t noticed the problem until my concert pianist friend brought it to my attention when he asked to do the direct comparison. Before getting the M-DAC I’d lived with the CDQ for over a year listening mainly to audio streamed from the NAS via the SBT and the async USB input. It was the same data as ripped from the original CD, via the best method, so ‘must be best’. It was of course the same data as proven by the exemplary SQ when using the SPDIF inputs, but I’d been careless and hadn’t used my ears. It was a case of ‘it is theoretically better’ so ‘it must be better’. My bad.

I was originally knocked out by the SQ of the CDQ so attributed my somewhat lessened enthusiasm for listening to music latterly to just becoming accustomed to so called ‘better’ sound …. although the reason for this has only become apparent in retrospect. When I first got the M-DAC, when playing CDs direct, I could swap over the XLRs and readily appreciate the improved SQ. I would say the degradation caused by the Async USB input to be significantly greater than the difference in SQ between the CDQ and M-DAC (when fed by the best source). I tried all manner of methods to ‘measure’ what I was hearing, all unsuccessful. It is amazing what the ear/brain can discern once an effect or artefact is heard or ‘learnt’.

I had become resigned to using the SPDIF inputs, but no problem, especially as I can play 192/24 files via SBT and coax . It just bugged me the theoretically superior transfer mode wasn’t working out. I can now sit back and relax with the SPDIF solution, get on with listening to music again and wait in anticipation for the MDAC2.

BTW, I am right in thinking the MDAC2 will ‘talk’ with the SBT without needing a USB hub?

No news yet on when my next visit to CZ will be. I must get a move on and arrange something. Thanks again for your quick reply. Best wishes to you and Renata (and the K9s).

Roger.

 

[JohnW]

FPGAs would be a very interesting proposition! I guess first priority will be integrating the physical FPGAs for first release, with firmware updates enabling them once the PCB is complete?

Yes that's the intention FPGA's on the PCB but they will be doing little on the initial release - overtime we will build up the FPGA functionality with firmware updates just like the MDAC software updates...

The risk element is time - but any slight delay will result in a more accomplished design for the sake of an extra month or so... so it really does not make sense not to do it - I'm sure MDAC owners can live with there current MDAC's for a little longer - then we can start to become very funky with the MDAC2's digital domain performance!!!

The full on FPGA firmware package (contingent on a dramatic step in performance) that we plan to release lets say after a years development we are considering charging an extra say GBP100... when you take into consideration that Dominik and to a lesser degree myself well have spent atleast a year developing it - hopefully this will be seen as acceptable.

The intermediate firmware releases we plan over the year will be for free...

 

[JohnW]

I am right in thinking the MDAC2 will ‘talk’ with the SBT without needing a USB hub?

Roger,

Yes - the MDAC2 will be based upon USB2.0, so no hub will be required...

I tried all manner of methods to ‘measure’ what I was hearing, all unsuccessful. It is amazing what the ear/brain can discern once an effect or artefact is heard or ‘learnt’.

indeed - Welcome to 'My' world!

 

[Dominik]

I can now also confirm I cannot detect any difference in SQ between either of the streamed SPDIF outputs from the SBT and the direct output from the CDQ. When swapping the SBTs over the Async USB input is always inferior.

So the situation is:
CDQ -> (coax or optical) M-DAC GOOD
NAS or PC -> streamed via Wi-Fi or Ethernet cable -> SBT -> (coax or optical) M-DAC GOOD
NAS or PC -> streamed via Wi-Fi or Ethernet cable -> SBT -> (Async USB) M-DAC BAD

I thought I had tried all user changeable menu settings but last night came across DPLL settings on the SPDIF inputs. By chance I played around with these and much to my astonishment found I could degrade an otherwise good SPDIF output from the SBT by selecting ‘High Bandwidth’.

To my ears the magnitude and character of the degradation when in ‘High bandwidth’ mode matches that of the Async USB input. So to summarise:
Streamed via Wi-Fi or Ethernet cable -> SBT -> (Async USB) M-DAC BAD
Streamed via Wi-Fi or Ethernet cable -> SBT -> (coax or optical) M-DAC (auto or low BW) GOOD
Streamed via Wi-Fi or Ethernet cable -> SBT -> (coax or optical) M-DAC (high BW) BAD
Roger.

Excellent post Roger! Rest assured I will go and double check the DPLL settings used while on USB input. There may be a bug hiding away - which would be really embarrassing, but at least it would fit into the pattern. I will let you (all) know ASAP.

Dominik

 

[travelfotografe]

Excellent post Roger! Rest assured I will go and double check the DPLL settings used while on USB input. There may be a bug hiding away - which would be really embarrassing, but at least it would fit into the pattern. I will let you (all) know ASAP.

Dominik

Hi Dominik, while you are at it, would it be possible to fix the -80dB startup issue as reported here http://www.pinkfishmedia.net/forum/showthread.php?t=134663 and where Adrian posted a diagnosis of the issue in post #31 of that thread. Fixing this issue will nicely complete the A10 firmware which you put so much effort into.

Thanks,
Leon

 

[stellablues]

Is there also still a concern that the A10 filters are 'off' compared to previous firmwares? I remember people mentioning that Optimal Transient XD did not sound as good as previously and that most had switched to Optimal Spectrum now being the more realistic filter. Some were mentioning a possible bug in the filters being named correctly in the interface or was that resolved ?

 

[jirij]

Its one of the reasons we plan to add FPGA power to the MDAC2 platform.

I thought you want FPGA only for the TDAC, to keep MDAC2 PCB at a more or less fixed price point with minimal extra features.

FPGA is kind of a very major change to that decision, in my opinion.

 

[paulski]

Is the TDAC still on the cards at some point?

 

[ChrisPa]

I thought you want FPGA only for the TDAC, to keep MDAC2 PCB at a more or less fixed price point with minimal extra features.

FPGA is kind of a very major change to that decision, in my opinion.

It doesn't have to be a major change. At its simplest the fpga could be implemented as a 'pass through', so it's just the cost of the chip on the main board

 

[PhilCTTE]

John,
Just confirming you received email in regards to shipping my upgraded Mdac.

Kind regards

 

[sam_cat]

The full on FPGA firmware package (contingent on a dramatic step in performance) that we plan to release lets say after a years development we are considering charging an extra say GBP100... when you take into consideration that Dominik and to a lesser degree myself well have spent atleast a year developing it - hopefully this will be seen as acceptable.

Not sure if this is possible, but could you build a 'time limited' demo version? Supports x hours listening then reverts to previous firmware..
Would allow a 'try before you buy' option.

 

[JohnW]

It doesn't have to be a major change. At its simplest the fpga could be implemented as a 'pass through', so it's just the cost of the chip on the main board

Yes, that's the idea for the initial release as we will have our hands full working on the main MCU / USB stack.

 

[JohnW]

Is the TDAC still on the cards at some point?

Very much so - if nothing else but for myself - I have my tubes sitting here!

 

[JohnW]

I thought you want FPGA only for the TDAC, to keep MDAC2 PCB at a more or less fixed price point with minimal extra features.

FPGA is kind of a very major change to that decision, in my opinion.

Not at all, there would have been a small CPLD in the original design idea - instead we will put down an FPGA.

 

[Dominik]

Hi Dominik, while you are at it, would it be possible to fix the -80dB startup issue as reported here http://www.pinkfishmedia.net/forum/showthread.php?t=134663 and where Adrian posted a diagnosis of the issue in post #31 of that thread. Fixing this issue will nicely complete the A10 firmware which you put so much effort into.

Thanks,
Leon

In fact I have just recently managed to find the long lost Squeezebox John left behind in China, so I'll have the opportunity to recreate and fix the problem.

 

[Ian M]

Hi John,

I hope you, and other forum members, will bear with me as I relate my observations of a problem which has been troubling me for some months. As there are so many others using the M-DAC with the Squeezebox Touch and Triode’s ‘Enhanced Digital Output’, it may be of wider interest.

John, I wonder if you could give me your thoughts on this problem as it’s been bugging me for too long now. I previously posted I was experiencing a degraded M-DAC SQ when playing files from a NAS via SBT as compared with the CD played using the 8200CDQ as a transport. (Actually it was a concert pianist friend who asked to hear the streamed version versus the CD direct, something I’d never done, who observed the effect first). That was back in May when I only had the CDQ.

A very brief description of the impairment would be a loss of detail, a collapse of the 3-dimensionality of the soundstage, sibilants are spread laterally and detached amorphously from the lower registers of the voice. The ‘clean’ good versions are also so much ‘easier’ to listen to and fatigue-free.

When a got the M-DAC I found the same problem existed. Since then I’ve done so many things to try to find a resolution it would fill a chapter or two.

Firstly the bit-perfect tests are passed without any problem. The USB buffer hovers around the 50% mark. On the SBT I can see the momentary frequency changing indication true Async operation. The degradation occurs with any source to the M-DAC from the Squeezebox Touch via the USB input when in Async mode. The sources could be either NAS or PC connected via a Netgear router, by either Wi-Fi or Ethernet cable, to the SBT. The same degradation occurs with internet radio sources. It doesn’t matter if files are transcoded on the server or the SBT, or sent over the network as wav files.

I have two SBTs both with Triodes EDO, two (different) USB 2.0 hubs and two USB isolators. The SBTs cannot output digital coax or optical at the same time as USB but I can stream the same content to the two SBTs and have one unit output SPDIF and the other USB and switch between them. Always the SPDIF is superior to the USB input. Running without a USB hub with Triode’s workaround does not change anything SQ-wise.

I can now also confirm I cannot detect any difference in SQ between either of the streamed SPDIF outputs from the SBT and the direct output from the CDQ. When swapping the SBTs over the Async USB input is always inferior.

So the situation is:
CDQ -> (coax or optical) M-DAC GOOD
NAS or PC -> streamed via Wi-Fi or Ethernet cable -> SBT -> (coax or optical) M-DAC GOOD
NAS or PC -> streamed via Wi-Fi or Ethernet cable -> SBT -> (Async USB) M-DAC BAD

I thought I had tried all user changeable menu settings but last night came across DPLL settings on the SPDIF inputs. By chance I played around with these and much to my astonishment found I could degrade an otherwise good SPDIF output from the SBT by selecting ‘High Bandwidth’.

To my ears the magnitude and character of the degradation when in ‘High bandwidth’ mode matches that of the Async USB input. So to summarise:
Streamed via Wi-Fi or Ethernet cable -> SBT -> (Async USB) M-DAC BAD
Streamed via Wi-Fi or Ethernet cable -> SBT -> (coax or optical) M-DAC (auto or low BW) GOOD
Streamed via Wi-Fi or Ethernet cable -> SBT -> (coax or optical) M-DAC (high BW) BAD

My M-DAC came with software v0.99/v0.97installed. (Raw digital supply is in the range 17.7v/18.0v). I wondered if a firmware change might have any effect. Today I tried installing the original v0.90 firmware but this wasn’t so useful as DPLL settings are not available but USB was still bad. I now have A10 firmware installed and I can replicate my findings exactly as I found last night.

As an aside I notice the ‘Actual frequency’ is displayed on the SPDIF inputs only when ‘Auto’ or ‘Low’ bandwidths are selected. ‘Actual frequency’ is not displayed with Async USB but there is also no DPLL option there.

It was my understanding, in Async mode, the M-DAC master clock controls everything and this sort of impairment should not be taking place – other things being equal it would be the preferred transfer mode. Nevertheless, using the same SBT stream, the Async USB input is behaving, as far as the degradation in SQ is concerned, as if it had an SPDIF input operating adaptively with high bandwidth DPLL selected. Although it shouldn’t be necessary, I am wondering what the effect might be (even if it were possible) of utilising all those stages of jitter reduction available on the SPDIF inputs?

I have for some time felt the impaired SQ was jitter related and what I have found this weekend seems to support that. Have you still got your SBT, John? Any chance you could have a listen when you have time please? And can anyone else please confirm my findings?

Roger.

I'm a bit puzzled here as I always understood that SBT to MDAC vis USB was good, it ceretainly sounds very good to me. But I have never tried it any other way. I am unable to experiment at the moment as somebody has taken my MDAC hostage .
Does this really mean that USB is not the way to go or will it be different for setups/ preferences etc. When my MDAC is "released" I will have to try optical.

Ian

 

[dtd]

Very much so - if nothing else but for myself - I have my tubes sitting here!

Phew! Cash set aside for the day!

 

[Plutox]

... It was my understanding, in Async mode, the M-DAC master clock controls everything and this sort of impairment should not be taking place – other things being equal it would be the preferred transfer mode. Nevertheless, using the same SBT stream, the Async USB input is behaving, as far as the degradation in SQ is concerned, as if it had an SPDIF input operating adaptively with high bandwidth DPLL selected. Although it shouldn’t be necessary, I am wondering what the effect might be (even if it were possible) of utilising all those stages of jitter reduction available on the SPDIF inputs?

Rest assured I will go and double check the DPLL settings used while on USB input. There may be a bug hiding away - which would be really embarrassing, but at least it would fit into the pattern. I will let you (all) know ASAP

This is truly interesting. One would have thought async USB to have been largely immune to this particular source of input jitter, yet here we are.

John or Dominik – what role does the DPLL play when the USB input is in use? I'd have assumed the single main advantage of async USB to be that the DPLL was not required at all in this mode, the clock rate being absolutely determined by the local crystal, no?

 

[Plutox]

... it was a concert pianist friend who asked to hear the streamed version versus the CD direct, something I’d never done, who observed the effect first

Even something as 'simple' as listening appears to be a multi-faceted jewel in which it is difficult to assimilate every aspect simultaneously. This was brought home on my recent visit to CZ to meet Bobby, Paris & Ella, during which I happened to bump into John & Renata

John was using a particular section of a particular track to evaluate one aspect of MDAC performance and he was homing in on something that I took to be a transient distortion on the original recording (something that I, subconsciously, had moved on from without blinking) which he demonstrated to be 'curable'! While an overall sonic character is clearly defined and (usually) easily analysed, effects that show themselves once in a blue moon are tricky to understand (and even harder to fix).

This experience reinforces my belief that the only truly reliable and repeatable means of comparing two sound qualities involves the burden of an instant switched comparison and, possibly, the need to have the test material on a repeating loop.

 

[JohnW]

This is truly interesting. One would have thought async USB to have been largely immune to this particular source of input jitter, yet here we are.

John or Dominik – what role does the DPLL play when the USB input is in use? I'd have assumed the single main advantage of async USB to be that the DPLL was not required at all in this mode, the clock rate being absolutely determined by the local crystal, no?

Yes, with Async USB the DAC's clock is Master - However internally to the ESS IC the DPLL is still active....

Lets see if the DPLL is set to default (Auto) or High BW for USB inputs ... and if indeed it makes any difference - but I suspect the issue could well be second order RF effects coupled into the MDAC via the USB link...

Give Dominik a few days to look at the code first before we start to form any conclusions.