advertisement


MDAC First Listen (part 00110100)

Status
Not open for further replies.
Yes it sucks, but I understand why they are using Mono. It makes it much easier to do cross platform development Roon runs on Windows, OS X and Linux.
For C#. If you're using mostly-standard C/C++, especially in their later iterations (C11/C++14), you can make very small and portable executables with just libc/libstdc++ dependencies which everybody has. However I understand that size is not everyone's concern.

When I look at HTOP on my RPI 2 it uses 75MB with dietPi and RoonBridge playing. Still a relative small footprint on a RPI even though RoonBridge is the major part of it :(
Oh, I meant ~30MB disk size for my OS, not RAM usage. :) It's already more than I would want (few years ago, I made a bootable image within 8MB), but this one has Qt5 and other big stuff.
 
Possible, but the Detox is power hungry - around 250mA not factoring any external "DAC" load.

With the MDAC2 VR PSU there is no need to consider a battery PSU.

That is good, as I already have Anker Astro Pro 2gen battery and according to papers it's 9v has output from 50mA to 2A. I am not sure about MDAC2 at this moment as I am in for FDAC.

One more question. As I understand MDAC2 does not depend on computer module, it can work with or without it. FDAC is different because all its user interface (screen, buttons) depends on this computer module. Maybe it is wise to get an extra computer board for spares (it should be quite cheap) as I think it will be difficult to get repaired it after 10 years? Or will it be possible to replace it with some more recent board?
FDAC board also looks will be quite complicated, was it 4 layer pcb? Will it still be repairable? Comparing to computer boards and mobile phones nobody expect them work over 10 years. They are replaced by warranty or new generation production. I expect FDAC use more then that. As it will be one time production quality control must be good. Personally I will be ready to pay some extra to help keep a stock of spares.
 
Are you sure its 9V output? If its a USB device I'd expect 5V?

For FDAC parts my only long term concern would be the LCD display, capacitors & Relays... but nothing else has a "lifetime" to worry about...

Edit:-

I read that the Anker Astro Pro 2gen battery is really 9V - thats Crazy as that going to damage any USB device that has a standard 5V input. Our small DAC's are damaged above 5.8V input! The USB Spec. specifies 5.25V as an absolute Max output.

Looks like it changes its output voltage depending on Device "Power IQ" ... but I dont see it outputting 9V without some kind of device ID communication...

These battery packs are really not the best anyway as they have internal switching PSU to regulate the Battery Voltage....
 
I read that the Anker Astro Pro 2gen battery is really 9V - thats Crazy as that going to damage any USB device that has a standard 5V input. Our small DAC's are damaged above 5.8V input! The USB Spec. specifies 5.25V as an absolute Max output.

Looks like it changes its output voltage depending on Device "Power IQ" ... but I dont see it outputting 9V without some kind of device ID communication...

These battery packs are really not the best anyway as they have internal switching PSU to regulate the Battery Voltage....

No, it has 3 standart USB ports which are 5V and separate connector which is 9V or 12V, user switchable (with a hold of a button) not device depended. Probably it has switching psu to regulate it.
 
Are you sure its 9V output? If its a USB device I'd expect 5V?

For FDAC parts my only long term concern would be the LCD display, capacitors & Relays... but nothing else has a "lifetime" to worry about...
The eMMC might wear down, depending on how often the Qt5 software writes the configuration to it - people expect ie. the volume setting to persist even through setting it and turning the unit off immediately. So the software needs to do some frequent writes.

One possible solution would be EEPROM or FRAM (http://www.fujitsu.com/us/products/devices/semiconductor/memory/fram/lineup/index.html), the latter being used for one unofficial RPi module, or some other kind of non-volatile storage. Or simply saving at most once a minute. (How does Audiolab MDAC handle this?)

Fortunately, the Compute Module is an off-the-shelf component and expendable, so a dead eMMC after some years (if at all) is hopefully not a big deal as the CM can be easily replaced.
 
I dont see the eMMC ware being an issue - I've never seen a failure. We store the settings in RAM and only transfer to EEPROM on powerdown
 
How about skipping writes if the volume hasn't changed?
Sure, I'm assuming the software is clever enough, but even then, it's a component with a known finite life. And if we use ~100MB out of the ~4GB eMMC for the OS, I was thinking that we could make the rest available for some basic music storage / recording, which is fine for read-mostly workloads, but could wear out on write-mostly ones. Still, it's "just" the CM, which can be easily user-replaced if that happens. (Depends heavily on the "cheapness" of the eMMC chip used, if the internets are to be trusted.)
 
Question is will this particular compute module will be available when it happens or will it be replaceable with another one current production module at that time. Is there some standarts on which we can rely?
 
eMMC should not be used for music storage or recording. Because it is not nessesary when there is a SSD installed. 4Gb is not enough for that anyway.
If there is not a SSD installed a USB key or SSD card can be used.
Then the eMMC will most likely never wear out
 
Question is will this particular compute module will be available when it happens or will it be replaceable with another one current production module at that time. Is there some standarts on which we can rely?

My guess is no one knows, but we will know then CM4 is released in some years. See no need to worry now.
 
Mcdt - can't see any clock input on the back, nor any description of it

So no evidence that it's innately designed for clock locking
 
I wouldn't be so pessimistic about the FDAC CD drive - even if it lasts only 2 years of heavy use, it can be easily replaced (at least on laptops) as the interface and form factor is fairly standard (at least the version with external cart, not sure about the cd-hole one). The benefit is that you don't have to clean it as it accumulates dirt/dust/hair inside. :)

Virtually all servers I use have 9.5mm drives which are interchangeable (all cart-based).

Though I can see the appeal of a good separate CD player.
 
As a long time Mdac owner and forum lurker I have a bit of a silly question.

I recently purchased a Google chromecast audio with a bit of a poor standard micro usb power supply. Would the Mdac USB input be able to power the chromecast or is it not powered and am I talking nonsense now? ;)
 
Mcdt - can't see any clock input on the back, nor any description of it

So no evidence that it's innately designed for clock locking

Yes unfortunately Audiolab did not add an external clock input on the MCDT - a missed opportunity :(
 
As a long time Mdac owner and forum lurker I have a bit of a silly question.

I recently purchased a Google chromecast audio with a bit of a poor standard micro usb power supply. Would the Mdac USB input be able to power the chromecast or is it not powered and am I talking nonsense now? ;)

"Welcome" to PFM with our first post :)

The MDAC USB is an "Input device" so it does not provide power to the external devices.
 
Status
Not open for further replies.


advertisement


Back
Top