advertisement


MDAC First Listen (part 00111000)

Status
Not open for further replies.
The MDAC2 media player (streamer) works with ANY device from internal memory, USB connected CD drive, USB Flash drive, SSD drive, NAS or network device, other devices on the local network, Internet sites etc.

From the users perspective, the operation of the streamer UI is basically the same irrespective of where the files are stored - which brings up some interesting "problems" with searching, should we just search local drives or a more global search and include searching Spotify and other steaming service music Libraries?

Basically we have made the Search engine mode sensitive, so if you search from the home screen it will search globally, but if your on your NAS it will only search the local NAS drive.

In my experiences of various player software;

Directly connected storage devices (HDD, memory card, etc) are generally scanned automatically by the player SW. In other words adding an album will be found automatically.

Storage devices accessible via the LAN (NAS, other computers, etc..) the user manually selects to add any folders to their library - and there is usually a chose to manual scan for updates/changes or automatically scan for updates/changes to the selected folder(s).

As for streaming services this is a different ball game as thier API needs to be incorperated into the player SW. And each time the user connects to the streaming service the player SW needs to update from their library as any changes since the user's last session are unknown.

Presenting everything as the same irrespective of source (i.e. as one huge library) can be a pain. Audirvana for example can access various streaming services, and it presents each streaming service as another music library (in addition to the users own music library), but the playlists and listening history are also kept separate. Roon has a different approach and presents everything together, but has much superior browsing capabilities. I like Roon a lot but it can be a pain when I want to browse just my own music and not streamed music and the two can't be separated (at least not that I know of).
 
I think most people would regard it as a big plus if all your sources (eg NAS + Tidal) are consolidated to make one library.
 
I think most people would regard it as a big plus if all your sources (eg NAS + Tidal) are consolidated to make one library.

Then your only option is to pay for Roon. (the streamer is cheaper than a MicroRendu buy the way)

The streamers Volumios library management will work exactly as it works today if you install Volumio on a RPI!

I do not think it is reasonable to expect more than that.
 
Is there any youtube video or instructions to help to remove the mdac sleeve? I need to check my unit for any leaking capacitors?

Thanks.
 
See if you can find my thread in the DIY room where someone helped me. Essentially, remove the 4 screws on either cheek, gently prise the front panel down (watch out for the cables...) then either unplug the front panel (for ease) or twis the front panel without unplugging and the board can be slid out of the back.
 
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.

Sadly there is no fix for the firmware for ANY device that uses the TAS1020B due to a design bug in the IC's buffer management - it has to force a buffer flush on split ehci-hcd transaction scheduling - to be honest its very poor form to split the scheduling in the first place - its only USB1.1 Data rates!
 
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.

See http://mdac.referata.com/wiki/Main_Page#Issues_with_MDAC_on_GNU.2FLinux all the way to the bottom - I stopped updating the workaround as it seemed to work 3.12+. Since then a different issue appeared (for me) as well, where MDAC slowly empties its USB buffer (goes down from 40% to 0% in about 5 seconds and then does a short "bzzt" sound before jumping back again), not sure what exactly would be the cause ("acknowledgement" URBs being sent too fast?) or which side is to blame, but I haven't been using MDAC the past months because of even worse issues on windows 10.

Coming back to linux, I'm using xhci-hcd (usb3 driver) on all ports, even usb2, which is normally fine, but when I used to have the 3.12 kernel, I was still using ehci-hcd (usb2 driver), which has a separate codebase and maintainer who, back then, rewrote a lot of it to support "problematic" devices like MDAC, so switching back to ehci-hcd could fix the buffer-emptying problem on 3.12 and beyond.
 
See if you can find my thread in the DIY room where someone helped me. Essentially, remove the 4 screws on either cheek, gently prise the front panel down (watch out for the cables...) then either unplug the front panel (for ease) or twis the front panel without unplugging and the board can be slid out of the back.

Tap Torx bit to ensure it is fully seated first..

Thanks.
 
Just saw that John got another award to his collection:
EISA DAC/HEADPHONE AMPLIFIER 2017-2018

Another 'Gold medal', congratulations John...;)

Thanks guys :), one of the better days in the lab here :)

Not bad for a little design that started out in life as the XMOS development platform for the MDAC2 :)

The DEVDAC for the Steamer is a step-up in audio performance over the project DAC so should make a decent little solution.
 
I really should rename the "Streamer" to say Media player as I'm also not registered with any streaming services - at best while working on PCB designs I use Youtube...

To be honest, I don't trust the quality of downloadable content - even purchasing 2 CD's from different pressing plants and they can sound different!

My personal use case for the "Media player" is to copy my media library onto internal storage /Flash Drive / SSD and just replay from the MDAC2 directly without the need for an external device - and a simple UI to select the tracks...



I might have a 22bit filter I could dig up for you...

John, whilst I still ponder MDAC2 or FDAC options, I've found both the 24/20 bit and HDCD filters for sale for the DaCapo/Ordinal. Which one should I look at purchasing ?

Ian
 
Is this as good as the original Mdac?

With a decent PSU better in some areas...

It uses a pair of ES9038K2M's which are based on the latest HyperstreamII ESS modulators - so a better DAC's then the MDAC'S 9018... but then the MDAC has a better analogue stage.

During the tedious MDAC2 development path we have found that the ESS DAC's are the sound quality "bottleneck" - limiting the performance gains of better analogue stages... so the little DAC has the better ESS DAC's to its advantage.

There will be a Battery Option for the DAC in the future.
 
I think most people would regard it as a big plus if all your sources (eg NAS + Tidal) are consolidated to make one library.

Ian,

Sorry - I consciously aware I need to work on your DAC's as soon as I have a moment free!

I know you have already more then patiently waited a very very long time - but could we agree that I work on your DAC as soon as I've completed the Discrete DAC PCB in (2-3 weeks)?
 
Status
Not open for further replies.


advertisement


Back
Top