advertisement


Audiolab Mdac - years have gone by, still linux support broken

mzry

Member
Hey there,

I have done some thorough google searches and I haven't found much on the issue, but in Linux the USB audio support for the Mdac is broken, and has been broken since around 2013/2014. I have seen mention of this mainly from people using a NAS system since they almost always run on a Linux varient, but obviously not many Audiophile type people run Linux otherwise there would be more threads over the net.

Here is a github page dedicated to a fix for the issue:

https://github.com/comps/ehci-mdac

"The Audiolab MDAC (an audio device) has some problems with recent Linux kernel versions due to split transaction scheduling in the ehci-hcd driver.
I'm going to investigate it further and push for a proper fix,
but in the meantime, there's this workaround."

This fix is now too old and not compatible with modern kernel versions, so Mdac is still broken. I have tried with various different distribtuions based on Debian and Arch, all are the same as it seems to be completely due to the kernel.

Now my point in posting this is: I know the developers of this device hang out on this forum occasionally. There are many DACs that work perfectly with linux. There are two ways for this to get fixed, one is for the Linux kernel to get patched for this specific DAC, or two; the developers of the DAC patch the firmware - which in all likelyhood is a smarter approach. It has been many years since an MDAC firmware update, what are the chances of this issue getting some attention?

For those who don't know, the issue is: when playing music there is a an audible 'ticking' sound like a metronome in the sound, usually every second.

Hope someone can help, I hope the developers can see this.
 
Audiolab have never released a firmware update for the MDAC.

The only updates have been by the designer JW himself.

One of the joys of computer audio is that with so many different types of 'interface'
both hard and soft it is nigh on impossible for firms to support all.
As you have said very few use Linux/MDAC.
 
Thinking about it I use an Aries Mini into my MDAC and that uses a Linux kernel.
So work arounds do exist.

Though Auralic gave up supporting Android because so many variants of hard/soft ware exist, and they employ a team of dedicated software designers.

If you wish JW to see this why not post in the ongoing MDAC thread ?

I suspect he is too busy to read all threads in the Audio section.

There are others on there who are computer savvy and may have a solution.

http://www.pinkfishmedia.net/forum/showthread.php?t=204221&page=47
 
Interesting, I think the issue only happens with usb3 integration though, perhaps those devices are usb2 only. But still interesting, I will test mine on my pi3. Sam what firmware are you running? I'm on a10.
 
We use CM3 with Volumio + MDAC with no issue....

Well I have actually changed motherboards to see if it would help the issue. I changed from my MSI Z-97 mobo to a Gigabyte H-97. I also re-installed my OS's and also tried different Linux varients. When inside Linux the issue persists even when changing between Pulseaudio or Alsa playback methods.

The problem definitely exists, maybe on just the more modern chipsets with the usb 3 integration etc. I e-mailed Linus Torvolds and showed him the github page and he has messaged some of his coders, he says the github page code looks cleaner and should be better.

This problem kicked in during the Linux kernel change in 2014 and has been around ever since. I am in contact with one of the Linux engineers and he is going to help me do some debugging to find the route of the problem.
 
jirij here on PFM your man to help solve the issue, but its not correct to make a blanket statement that MDAC"s broken on Linux as many of us are using Linux based devices with MDAC - its just (sadly) broken on some versions.

For sure USB3 ports even on PC's have been known to cause issues, I'm not sure why a faster controller has to resort to splitting ehci-hcd transactions on slow speed USB1.1!

I'm sure jirij can help :)
 
It does seem a little unfair to label it an Mdac issue when it's actually a very rare Linux issue and pc hardware issue.

The Mdac was designed years before USB 3. Maybe take it up with IAG who sell the device?
 
It's a very MDAC specific issue (probably TAS1020B specific) as I haven't seen any other DAC, XMOS-based or not, that would have similar issues, not even the c-media ones.

The problem is, if TAS1020B handles split transactions badly, that anything other than native USB1.1 (computers from ~1997 to ~2004) has potential for issues as split transactions are necessary for USB1.0 and 1.1 to work on 2.0 and 3.0 links. They are technically a host+hub side thing, the device doesn't need to know about them (by design, to support prehistoric USB1.0 devices from the '90s), but the device must also not make any out-of-spec assumptions about latencies on the link (and <USB1.1 latencies are in miliseconds, not smaller).

Because any latencies are going to get completely out of whack due to what split transactions are, by design - http://www.usbmadesimple.co.uk/ums_7.htm#split_trans. This is why a simple linked-list traversal reversal "fixed" the MDAC issue earlier (it just changed the time data were scheduled/sent at) and that's also why USB3.0 has more problems, because it needs to do the translation twice, I think, for compatibility with 2.0 hubs.

So far my digging into this (in years past) have showed MDAC to be extremely sensitive to any URB timing, much more so than any other USB DAC.

The thread author is already on linux-usb list and Alan Stern (ehci_hcd maintainer) is trying to help him debug the issue using dynamic_debug, but I suspect it's going to be an xhci_hcd problem (different maintainer) as I'm seeing the same issue on xhci_hcd, but not on ehci_hcd, as I mentioned in the First Listen thread.

edit: As a sidenote, external USB3.0 or USB2.0 hub would likely work, as it will "re-clock" traffic due to performing split transactions itself.
 
Jirij,

This is a bug related to the TAS1020B - its easy to be so judgemental today when there are many USB solutions, but when MDAC was first designed USB audio was not even accepted by the mainstream community, there was no information from MS about Async audio support, and dont think for a moment Linux supported USB audio nativity (atleast not Async USB) - USB was simply perceived as not "HiFi" and had no place on "proper" HiFi equipment - it was very earlydays.

Early USB implementations where where poor - Async USB changed this and the ONLY device that could be used as an ASync device back then was the TAS1020B which is why many early designs used it and suffer from its weakness's.

You cannot compare XMOS or C-Media to the TAS1020B, these are USB2.0 devices and far more advanced - they have befitted from the market (and avoid the early technical shortcomings) for ASync USB devices created by such early devices as the 1020.

Yes, TAS1020B is a flawed device by today's standards - but its all to easy to criticise from ivory towers once others have done the hardwork and progressed a technology over time. USB audio is now better defined and supported - but we are only here now because of the early pioneers.

Please be kind to the 1020B and respect elders, especially those who have brought us to where we are now.
 
I don't think I've used any harsh language towards the chip, I'm just stating what I found so far. The c-media chip I measured was in a ~2010 DAC and we've had consumer USB audio going at least back to 2003 (Audigy 2 NX that I had), but you're right that it wasn't Asynchronous and it wasn't of much interest to "audiophiles" or "hifi". Truth be told, those early devices had their own (non-timing) issues, mostly with non-standard USB EP ids, so kernel hacks and custom windows drivers were needed.

Let's just get this behind us with MDAC2. :)
 
Although I am impressed at some of the technical response from this thread, I think we're forgetting two important factors: the customer, and the future. Mdac has been in the market for a few years now, it might feel like I'm digging up a dead donkey to the designers, but don't forget that these models are still being sold in enthusiast audio stores all around the world today. Even though these issues might not have existed initially doesn't excuse the fact that with hardware changing and operating systems evolving and more customers moving towards Linux - that's a lot of poor customer experiences to deal with. Then what about the thousands/millions? Of Mdac owners on the market who might eventually move to Linux with their modern usb3 rigs? Do they throw their Mdac in the trash? I certainly won't and that's why, as a customer, I am trying to bring this to the right people's attention. So far I'm extremely happy with the response from the Linux foundation, the main man himself Linus Torvolds actually took my email seriously and now I'm helping to troubleshoot, even with no programming knowledge, because I love the product.
 
From the discussion above, the USB interface components used in the design are old with innate limitations. So either these components need to be replaced or the OS USB drivers need to be fixed to compensate.

The design was a subcontract activity for Audiolab. Audiolab continue to manufacture and make their profit on the product. Take it up with them.

You seem to imply that the original designers have a responsibility for fixing an old design which uses an old chip with innate limitations, over and above the manufacturer who continues to make the profit. If that's not your implication, then I'm sorry I've understood you.

Or try a USB hub as suggested above?
 
From the discussion above, the USB interface components used in the design are old with innate limitations. So either these components need to be replaced or the OS USB drivers need to be fixed to compensate.

The design was a subcontract activity for Audiolab. Audiolab continue to manufacture and make their profit on the product. Take it up with them.

You seem to imply that the original designers have a responsibility for fixing an old design which uses an old chip with innate limitations, over and above the manufacturer who continues to make the profit. If that's not your implication, then I'm sorry I've understood you.

Or try a USB hub as suggested above?

ChristPa, I did email Audio lab without a response yet. But when and if Audiolab take it seriously who do you think they will turn to for advice? The original designers. Also you would think that the designers would have more passion about the products performance to take this seriously, you could safely assume they have more direct links to Audiolab in order to get this issue addressed. I am just relaying this information to the most important people involved, with the assumption that it might make a difference.

And the USB 2 hub didn't help :(
 
mzry,

I'm the original designer - and as has been stated the limitation with the USB IC used - there is no hardware or firmware solution.

I'm not sure why Linux broke the functionality with later software releases - but I'm sure they had there reasons - no one deliberately goes around trying to "break" products. I'm sure they had technical requirements to change the drivers and cannot be expected to support all legacy hardware.

So many products are "junked" when MS release new Windows versions and don't support the old device drivers - so you can hardly expect Audiolab to offer a lifetimes support!

I would REALLY LIKE YOU TO BE CLEAR AND TELL ME WHAT YOU THINK I CAN DO FOR YOU? The design is 6 years old and has problems in some systems with an interface that did not exist when it was originally designed!

I really struggle to comprehend your perspective - it was designed for USB 1.0 / USB 2.0 ports, there is NOTHING that claims it will work with USB3.0!

So should I go to my TV manufacturer and say - "hey what you going to do about it? my TV I bought 6 years ago does not support the latest 4K standard" when it never claimed to, and 4K video did not exist when the TV was originally designed? Sure the old model might still being sold in limited numbers - but its sold on the basis of the original design Spec.

Yes - this sounds crazy, but this is what YOUR asking from me!

For those who still purchase an MDAC today they purchase it on quoted Spec. and NOWHERE do we claim it to be compatible with USB3.0 ports.

I do my best to support my old designs - but sometimes hardware limitations are just that! I cannot support every "fringe" application / system forever!

I use many Linux devices with the MDAC - no problems, so one can hardly say "still linux support broken"!

Just out of interest - what nationality are you? The reason I ask is that its my experience that persons from Finland, Sweden (Nordic country's in general) and Germany can tend to have some "crazy" product support expectations - the Fins especially are must troublesome in this regards.
 


advertisement


Back
Top