MDAC first listen (part XXII)

[JohnW]

While waiting for the resistors to arrive from the US - I decided to tackle the MMAV bypass units - or at least the mechanical modifications.

https://dl.dropboxusercontent.com/u/86116171/L2MDAC MMAV.jpg

OK - I'm going to have to buy a decent pillar drill - cheaper to buy a new one then trying to dig out my old one from the storage unit...

With the existing software, AV bypass is enabled when the unit is powered off.

With future software builds - the software will be able to detect a MMAV unit and AV bypass can be selected via the Front Panel Source Sel buttons (and via the Remote Control).

I'm happier now that the Bypass Option can be selected via the Source Sel / RC - now not so "Mickey Mouse" ....

 

[JohnW]

If that device really does some rescheduling, then it *might* work. USB hub probably won't fix the issue as it isn't in fragmenting the blocks themselves.
I wrote *might* because such device would break the guaranteed latency rule that USB provides. Passing the feedback isochronous channel could also be tricky (the data channel would be effectively double buffered).

I'd really like to resolve this with the Linux kernel upstream, so the Synology developers can pick the fix from there upon their next rebase.

Depending on the analysis of the problem, there might be some MDAC firmware update needed, but I really want to try fixing this in the kernel as their basic ideology is "don't break existing stuff" and such ideology applies even to workarounds for existing firmware bugs, regardless of device.

However as discussed with Alan Stern before, the current full speed ehci scheduling code is in a really bad state and no rewrite is on the horizon, so the patches either get reverted (and break the stuff that started working by doing the fix) or some kind of workaround is implemented.

jirij,

Thank you for your support with the Linux kernel

 

[JohnW]

Dear john, thank you so much for your reply. On the display is written: "Scanning for match" for all the test and the files resolution (44.1 or 96). Nothing else as passed test or failed test. Why? I also try to playing the file test directly from itunes but the result is the same.

When the MDAC displays "Scanning for match" the data from the MAC is so corrupted that the MDAC cannot detect the "Start of Frame" of the Bit-perfect test.

You can try:-

1. Insure the Bit Perfect file is not saved in a lossy format on your MAC (it must be Bit perfect).

2. Configure the MAC to 44.1KHz - 24 Bits

3. insure your MAC's volume slider is set to 100%

4. Disable Amarra and via itunes directly replay the test file.

Before running the Bit Perfect test, turn the MDAC's volume down to Min (-80dB) and insure that the MDAC displays 44.1KHz 16Bits when you replay the test file.

To run the file, first enable the Bit Perfect test mode on the MDAC - and ONLY then replay the test file. The MDAC must be in "test Mode" before the start of the BitPerfect test file is replayed otherwise the MDAC will miss the start of test "Header" in the test file.

 

[JohnW]

That's better! Thanks fot the update

Acrylic ReSponse Minis have already arrived to house MDAC + PSU.

3 different coax interconnects are on order to try, two with WBT 0110 nextgen ag connectors and one with Oyaide pure silver cable (to reduce incoming vibration) + a cheapie.

I will also consider optical.

Then I could sell the CDQ and buy either a Rega Apollo R or Westlake MTRN with the proceeds. That way the MDAC L2 gets pride-of-place alongside one of these half-width transports.

Don't bother wasting your funds on the expensive Digital cables - any GBP10 cable will do.

 

[JohnW]

Hey john in response and likely not related, I have found that my headphone jack has always been fatiguing/over revealing and I remember you stating that the output between Rca and headphone jack were under the same circuitry and only a relay was used to switch between the two. I get two totally different signatures between rca and HP jack. Could this be a relay problem ?, I never ever have liked the headphone output and always use rca for speakers, I prefer much more my Wolfson mini DAC for my headphones. They are 50 ohm headphones could that contribute why ?.

Also john if it uses the same circuitry could I not plug my HP into the rca ? Or is there added headphone circuitry for the HP jack....

On another note john I used to have a stuck relay problem with a.10/a.09, you had said it was a hardware issue and not firmware related and I don't disagree however I had been using 0.90 for months after that and decided to try a.xx for a change and instantly had the relay problem again switched back to 0.90 and no problems again. Just reporting anyway, still probably is hardware but something in that firmware tripping the fault. Still prefer 0.90 anyway .
Thanks John.

Each headphone output amplifier is different - after hearing many apparently 'HiEnd" headphones at recent show (Munich / CES) I can understand why a "less revealing" headphone amplifier might be preferred - must headphones are either Bass heavy or Bright... I liked Jirij's headphones we listen too this weekend... (Sorry forgotten the make / model AKGs??? made in Austria?).

Due to the L2MDAC analogue stage rebuild, the Headphone amplifier is very different to a standard MDAC's...

 

[DANOFDANGER]

Each headphone output amplifier is different - after hearing many apparently 'HiEnd" headphones at recent show (Munich / CES) I can understand why a "less revealing" headphone amplifier might be preferred - must headphones are either Bass heavy or Bright... I liked Jirij's headphones we listen too this weekend... (Sorry forgotten the make / model AKGs??? made in Austria?).

Due to the L2MDAC analogue stage rebuild, the Headphone amplifier is very different to a standard MDAC's...

Yea i have experienced the same thing, a lot of headphones i have listend to seem to focus on the unaware type people and are bass heavy. Like audio technicas and all those rubbish dr dre sets. Sennheiser have always been more neutral to me and match the characteristics of speakers. I trust them heavily, i also have listened to akgs and they are good. Good thing about headphones is they are closer to the level of linearity due to their simpler deisgn and less restricted limitations (no crossover/multiple driver).

Thanks for the info john.

 

[jirij]

jirij, Thank you for your support with the Linux kernel

No problem, happy to help. If anything, I need it for myself. (sort of like you with your CLSs)

I liked Jirij's headphones we listen too this weekend... (Sorry forgotten the make / model AKGs??? made in Austria?).

AKG K702. Even though they're "just" supposed to be K701 with better QC and detachable cable, they sounded somewhat better (warmer) in direct comparison to K701, both having 600+ hours of "burn in".

USB hub probably won't fix the issue as it isn't in fragmenting the blocks themselves.

I'd like to clarify that a bit. The issue is with guaranteed bandwidth with "split transfers", that is half/full speed (USB1.x) transfers over a high speed (USB2.0) link. When you plug a full speed device in a high speed hub, the hub communicates this via SPLIT all the way to the host. This is to preserve the high speed link for other high speed devices on the hub, so that it doesn't have to degrade to full speed entirely.
It applies to ports on motherboard / NASes as basically all of these (EHCI-compliant) have an integrated hub, providing multiple USB ports.
For more, see the USB2.0 spec, chapter 11, section 11.18, "Periodic Split Transaction Pipelining and Buffer Management". More reading for me as well

 

[pkerai]

If that device really does some rescheduling, then it *might* work. USB hub probably won't fix the issue as it isn't in fragmenting the blocks themselves.
I wrote *might* because such device would break the guaranteed latency rule that USB provides. Passing the feedback isochronous channel could also be tricky (the data channel would be effectively double buffered).

I'd really like to resolve this with the Linux kernel upstream, so the Synology developers can pick the fix from there upon their next rebase.

Depending on the analysis of the problem, there might be some MDAC firmware update needed, but I really want to try fixing this in the kernel as their basic ideology is "don't break existing stuff" and such ideology applies even to workarounds for existing firmware bugs, regardless of device.

However as discussed with Alan Stern before, the current full speed ehci scheduling code is in a really bad state and no rewrite is on the horizon, so the patches either get reverted (and break the stuff that started working by doing the fix) or some kind of workaround is implemented.

Yes, they wouldn't bother with redesigning updated software form the ground up anyway.

 

[pkerai]

I tried a Synology NAS direct to M-DAC via usb. It worked OK. but the only audio player was dsm which was pants.

Now using Win 7/JRiver>M-DAC via USB.

Yes, but did you get any clicks in either setup.

Im not sure if anybody has tried using Musical Fidelity V Link 192.
It needs no power supply and outputs to galvically isolated coaxial digital or balanced outputs.
This is designed to address buffer issues I think, not sure about the clicking though.
Anyway this device costs around £200.

 

[jirij]

Yes, they wouldn't bother with redesigning updated software form the ground up anyway.

I was referring to the Linux kernel upstream, not the Synology downstream version. According to the MAINTAINERS file, Alan Stern is the primary usb ohci/uhci/ehci driver maintainer.

Im not sure if anybody has tried using Musical Fidelity V Link 192.

That's not an "usb buffer" or usb-usb rescheduler, it's a regular USB->SPDIF converter. It uses USB2.0 in high speed mode, so no need for split transfers or full speed support, effectively overcoming the issue at hand. Therefore yes, that would likely solve your problems, be that either full speed frame scheduling or USB3.0 itself.

As I wrote in my PM reply to you, try regular USB2.0 hub, it might be just an USB3.0 issue.

 

[Vaughan]

While waiting for the resistors to arrive from the US - I decided to tackle the MMAV bypass units - or at least the mechanical modifications.

https://dl.dropboxusercontent.com/u/86116171/L2MDAC MMAV.jpg

OK - I'm going to have to buy a decent pillar drill - cheaper to buy a new one then trying to dig out my old one from the storage unit...

With the existing software, AV bypass is enabled when the unit is powered off.

With future software builds - the software will be able to detect a MMAV unit and AV bypass can be selected via the Front Panel Source Sel buttons (and via the Remote Control).

I'm happier now that the Bypass Option can be selected via the Source Sel / RC - now not so "Mickey Mouse" ....

Great news !

 

[JohnW]

Great news !

Yep - your unit I was wondering if you would notice your Ser#

Hope your recovering well, I've always maintained sports is bad for you - that's why I'm the figure I am

 

[DANOFDANGER]

I asked you before john but you didn't respond to all my questions so il ask one by one, I do understand your busy man though .
Is the headphone output circuitry the same as the rca. ?
If yes can you use headphones on the rca via rca to 3.5mm adapter ?.
And also my relay problem from previous post, just info on whether firmware is inducing a hardware fault ?.

Thanks.

 

[shaolin]

I asked you before john but you didn't respond to all my questions so il ask one by one, I do understand your busy man though .
Is the headphone output circuitry the same as the rca. ?
If yes can you use headphones on the rca via rca to 3.5mm adapter ?.
And also my relay problem from previous post, just info on whether firmware is inducing a hardware fault ?.

Thanks.

Hi DANOFDANGER,

yes, it's all the same, you can use RCA output for headphones easily.

shaolin

 

[Asphaltradler]

I'd really like to resolve this with the Linux kernel upstream, so the Synology developers can pick the fix from there upon their next rebase.

Depending on the analysis of the problem, there might be some MDAC firmware update needed, but I really want to try fixing this in the kernel as their basic ideology is "don't break existing stuff" and such ideology applies even to workarounds for existing firmware bugs, regardless of device.

However as discussed with Alan Stern before, the current full speed ehci scheduling code is in a really bad state and no rewrite is on the horizon, so the patches either get reverted (and break the stuff that started working by doing the fix) or some kind of workaround is implemented.

Sorry for plunging in here,
I'm no Linux expert but have a question.
I'm using the MDac with a Network player (SPDIF) and an antique Pentium M-based notebook (Win XP) without problems.
Now I'm considering buying a small netbook with Atom oder AMD processor because the notebook is a bit too big and sometimes noisy on the HIFI shelf and XP will be running out soon.
Did I get that right that there are issues with Linux and MDac over USB, or was that only the NAS you wrote about? Because small netbooks are often offered with Ubuntu now (12.04 seems to be the one often mentioned).

Any experiences someone with a good quiet netbook? I thought about an Asus EePC R051 or R11, Acer Aspire One 725 or something like that.

I like to use Foobar2000 with the Waveform seekbar plugin, and that is about what the Pentium M 765 is able, but with too much fanning for my liking.

Asphaltradler

 

[ilmostro749]

Same issue.
2 solutions:
Hardware: a usb repeater which takes the existing usb port from the synology nas and makes the changes and repeats a usable usb port without these issues.
Havent found something like this yet. Also, some people say this issue is just with usb 3.0 ports and not 2.0 on the synology.

Software: too complicated for me. unless someone can compile some add ons to synology dsm software?

I got the Synology working last week after messing about with a Hub (the Hub doesn't fix it). What I found by accident was that the front USB port is a USB 2.0 port, and that works (without the Hub)

It's still not perfect;

It won't play anything better than 16/44 files (even though the Hi-Quality option is set)

Won't pass the bit perfect test.

Can't do gapless playback.

So really the Mac/iTunes set-up is still the better one.

 

[EIffel]

Great news on the MMAV and the upcoming firmware support.

I hope the resistors will arrive soon, as my MDAC should be undergoing heart surgery very soon, if I understand it right ;-)

 

[Steven Toy]

Don't bother wasting your funds on the expensive Digital cables - any GBP10 cable will do.

If the cheapie is as good as the others I will keep it and send the others back.

Optical or coax?

What do you use yourself?

 

[JohanH]

Hello John,

I'm partly hoping that you will agree with my findings in this.
The MDAC was very good before and when it came back not so much.
If you don't find anything wrong (apart from the relay) something would be faulty elsewhere in the chain, but I'm struggling to think what that might be.
So yes, also eagerly waiting for your findings.
But please don't worry, everything will be ok in the end

Johan

I may have found the culprit....
The only thing changed when I put the L2 MDAC back was that I disconnected the LSP wiring. Mine are suitable for biwiring so there's a small wire between woofer and tweeter connections. I used teflon insulated silverplated copper for those. Possibly when putting it back I connected to the oxidised bits. Yesterday I replaced the wire with "normal" copper and I notice a difference with the current DAC (less harshness / fatigue).
Not sure but it might be an explanation.
Still curious: it might be both...

 

[JohanH]

If the cheapie is as good as the others I will keep it and send the others back.

Optical or coax?

What do you use yourself?

IIRC optical is not guaranteed upto 24/192: I use coax