1. Things you need to know about the new ‘Conversations’ PM system:

    a) DO NOT REPLY TO THE NOTIFICATION EMAIL! I get them, not the intended recipient. I get a lot of them and I do not want them! It is just a notification, log into the site and reply from there.

    b) To delete old conversations use the ‘Leave conversation’ option. This is just delete by another name.
    Dismiss Notice

MDAC First Listen (Part 00101001)

Discussion in 'audio' started by JohnW, Aug 12, 2015.

Thread Status:
Not open for further replies.
  1. Ciunas Audio

    Ciunas Audio Trade: Ciunas Audio

    Exactly! We don't yet know what the issues are.
  2. BigDog

    BigDog pfm Member

    Your confidence in John's capabilities and, as someone else noted, his non-BS approach is reassuring...much like my opinion of Nelson Pass after doing business with him for 30+ years.

    That being said, I believe that "In God we trust, all others bring data".

    I see from the referenced DETOX description that it is a series of 3 USB hubs(?) which are daisy chained with 3 RF filters. IF I understand correctly, the USB hubs regenerate the USB data, not unlike the REGEN.

    Unless there is proprietary information involved, to reiterate, is there a reason why the DETOX might be preferred?
  3. JohnW

    JohnW pfm member


    USB is a very nice simple "Plug and Play" solution - its the perfect interface for local audio connection - with Ethernet you have to be entering IP address, Firewall pass though etc. gosh its a bag of hurt - I just want to plug a unit in and it simply works.... well as much as any PC device does...
  4. BigDog

    BigDog pfm Member

    To whom it may concern,
    I am a registered member who thought he was subscribed to
    MDAC First Listen (Part 00101001)
    BUT I have not gotten recent posts nor do I show as being a subscriber despite several attempts.

    Please advise.

  5. Ciunas Audio

    Ciunas Audio Trade: Ciunas Audio

    Right & it remains to be seen if the Detox confers complete immunity to upstream variations - this will be the decider, right?

    Right but if you are an "audiophile" then you have a different perspective to joe ordinary - the perspective is that you have to do some work to get your audio sounding great - just throwing any ol' crap together & expecting it to sound great is anathema - the same applies here.
  6. Richard Kimber

    Richard Kimber pfm Member

    Most of the setup is by automatic detection, you don't have to do anything. The dlna client detects the server, the tablet app detects the client. etc. The only issue I've ever faced is ensuring the correct port is open on the PC firewall. This is not a big deal, and no deal at all if the server you are using has decent documentation.

    - Richard.
  7. BE718

    BE718 pfm Member

    Agreed that we don't yet know the ultimate efficacy of the detox, however that still isn't the decider because it misses the point. If the dac is ultimately still affected by variations in incoming data jitter, then the dac is still the item at fault.

    The variations on USB are normal. The engineering solution is for the dac. I know this potentially trivialises the difficulty of the solution, but for example if the operation of the USB receiver is modulating the ground plane and causing issues for the clock then you need to design the dac to isolate the problem.

    See my previous reference to spdif jitter and how that was once a problem.
  8. JohnW

    JohnW pfm member

    The Detox works on "cleansing" the USB Data on various levels:-

    1. RF filters the incoming Data, between cascaded USB stages & on the final outputs.

    2. Each USB Hub stage adds its own Jitter attenuation, clock from the SAME reference clock so that you don't have "beating" between USB clock domains.

    3. Clock lockable to the MDAC / FDAC audio Master clock via the DAC clock output - this insure the USB clock in the Detox and MDAC / FDAC are synchronised - eliminating unwanted clock beating effects.

    4. A Spread spectrum mode is selectable that adds random white noise to the clock to decorrelate the remaining phase noise spuire.

    5. Provides a Clean low noise USB power to the DAC (important for the FDAC whose Galvanically isolated USB input stage is powered via the USB host device).

    6. Two USB Outputs:- The first is a galvanically isolated USB1.1 (12Mpbs) and the second output supports full High speed 480Mbps USB 2.0.

    7. Supplied with a simple linear AC mains adaptor.
  9. misterdog

    misterdog Not the canine kind

    As I have posted before 'Bit - Perfect' only refers to the 'message' being complete and as it should be.

    It does not mean that there is not crap,crud, or runts travelling along with the signal.

    I bought a Win 7 laptop hoping for improvements over my PC.
    Later I bought a Win 8 laptop and was surprised at the increase in SQ.

    Both passed the bit-perfect test, both running JRiver.

    Please stop believing bit-perfect is PERFECT it isn't.
  10. BE718

    BE718 pfm Member

    Well, that's not strictly true. It's not fundamentally different to USB. Data integrity is no problem, but clearly the reciever circuitry has the potential to cause secondary issues for the dac. Rf noise, supply noise, ground plane modulation etc.

    All can be designed around.
  11. fusion5

    fusion5 on the dark side of hifi...

    Actually it's not that simple. The FDAC would need more hardware and software (firmware) to implement the DLNA player/renderer capabilities. Also the firmware would be in need of constant upgrades to keep up with new file formats and other changes (like IPv6 support). IIRC John has stated more than once that he and Dominic can't provide this kind of support.

    Keeping streamer and DAC has several advantages. The FDAC has the potential to be a state of the art DAC for a longer time period than any streamer or streamer/dac combo I can think of.

    Despite that you can't just drop the USB input from the spec sheet. For some of us this a required input format like spdif for others.
  12. misterdog

    misterdog Not the canine kind

    How will you see our replies then ? :confused:
  13. JohnW

    JohnW pfm member

    I hear you, but be experience has always been that nothing is that simple with computers, I ALWAYS seam to have problems installing a device / router / printer etc.

    With Computers there are just so many variables - USB has its own share of issues, but the USB "plug and play" is easier much easier then networks connections.

    Oddly enough, I'm old school and pretty anti computers - I just want to listen to music without the need to read a manual to set-up firewalls and other such joys...

    No matter how easy it seems to you - I can say that for most people it would put them off, and I don't have the resource to support customer installation issues - even if its just simple problems to resolve... Even USB not a walk in the park but its for sure easer then IP based networks.
  14. tonerei

    tonerei pfm Member

    Good you can admit it JohnW. I would agree it is a hassle and I only got as far as I have DIY with a huge amount of tech support etc from a group of like minded friends. For the 'ordinary Joe' Itemaudio, Hifidelit or SmallGreenComputer or HDPlex or purchase from somebody like AudioPhil to have all that grunt work done for you.

    Optimizing the PC transport brings huge improvements. I don't have the regen myself yet but have heard it in my system. On battery supply it certainly warranted considering. A lot here are hoping their dodgy laptop or rickety Komputer will be radically transformed by a regen. I would have my doubts. The old maxim crap in crap out holds. BTW I aint no engineer so my view is 'joe public'
  15. JohnW

    JohnW pfm member

    I see the "second order effects" with Ethernet and wifi far worst then with USB which is so much simpler.

    Not such an issue as the DSP & FPGA are operating synchronously to the Audio master clock - we will also use "Quite conversion" where the DAC MCLK is out of phase with the FPGA / DSP and operates on the "Quite" clock phase.
  16. BE718

    BE718 pfm Member

    No, totally disagree. Being an audiophile does not mean that. The computer skills will be beyond many and the results variable and unquantifiable.

    This is a dac problem and that's where the solution lies.
  17. jirij

    jirij Virtual Member

    (I didn't want to respond on this earlier as some people are too obssessive about the idea of using computer networks to connect DACs, preaching benefits when they have no clue about the technology, but you're IIRC not one of them, so let's hope to keep this civil. :) )

    Well, we can eliminate "from the other side of the world", because that would be L3+ protocols which aren't necessarily Ethernet-specific. Regarding the actual IEEE 802.3 standard itself, it's not a bad way to transfer data - it uses (again, IIRC) the manchester encoding, making it very easy to isolate, since there's no DC component (unlike USB). The RJ-45 jack & the cat* cables are also not bad, although not very suited for tablets, smartphones, etc., all of which can still have microUSB OTG (able to feed an USB DAC).

    Then you get to the protocol details - 802.3 specifies a primitive header of dst+src+ethertype, but not much else. Anything else is *not* Ethernet. You can either decide to build directly on this primitive header, creating you own protocol on a "near hardware" level, or you can slap something like IP on the top (needing one to configure IP addresses or rely on DHCP) or even TCP/UDP above it (as a base for your protocol) with all the horrible implementation details - ie. very big retransmition times and slow recovery for TCP. You could also go for existing solutions like RTSP, but those don't have any feedback channel (like asynchronous usb has) and pretty much have to use a PLL.

    And when you get past this mess, you run into virtually no support on the OS side. If you just made you own protocol above Ethernet, you don't have any drivers (for win/mac/linux/bsd/.. or any proprietary streamer), any players or means to get the computer to transmit the data as if there was a sound card on the other end. There's a way to work around that, like DLNA (which again, uses RTSP, see above), but that still has the same driver issue - it may work for "simple" people, who just want to use a simple software player, but not so much for ie. web browser (youtube), computer games, DAW or any other use case where a real "sound card" is required.

    Compare this to USB, which defines audio streaming in the standard, is supported by multiple OSes, is very widespread and doesn't seem to stop (compared to Ethernet not being present on mobile devices) to the point where it "killed" Thunderbolt. The same USB, which again defines - in the standard - things like HID and existing software support for play/pause/seeking. The same USB, which allows you to record, not just playback.

    Now get in the shoes of somebody like JohnW. Would you really go try changing the world to use Ethernet (or whatever network streaming) for connecting DACs or would you just use the best tool available *now*? Would you rather develop your own protocols, locking your customers to your solutions (and having to support multiple OS versions, hello microsoft), or would you just use a widespread standard?

    (And the best part is that Ethernet doesn't even get you the benefits some here preach - compared to USB, it only breaks the DC path, all the nasty RFI and jitter are still there!)

    None of the above says that it's impossible or that USB is technologically better - it's simply much easier to use in the existing software ecosystem.
    Sorry for such long post, I hope it sheds some light on why the world is not so simple. :)

  18. Richard Kimber

    Richard Kimber pfm Member

    I didn't mean to imply that this should be built into the FDAC. I was just responding to the idea that we have no other option than USB, and that the ethernet solution is more straightforward than many people think.

    - Richard
  19. BE718

    BE718 pfm Member

    Thanks john, that allays one of my small concerns
  20. Richard Kimber

    Richard Kimber pfm Member

    You're just assuming that the data that arrives in the buffer has been affected by crap, and/or that the crap is allowed by the designer to get into the rest of the system.

    I'm not sure how this bears on ethernet vs USB.

    - Richard
Thread Status:
Not open for further replies.

Share This Page


  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice