advertisement


MDAC First Listen (Part 00101001)

Status
Not open for further replies.
It is being designed by John therefore it will be better ;-)

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?
 
Well ... there are other ways. How about ethernet? We can receive bit-perfect data from the other side of the world, so it seems an obvious option.

- Richard.

Richard,

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...
 
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.

Thanks.
 
Sorry I can't agree with that position, if we are using normal pcs, the the dac must be able to deal with the variables that will create. This is absolutely a case of the dacs internal design / operation being affected by a normal variation of the incoming data.
Right & it remains to be seen if the Detox confers complete immunity to upstream variations - this will be the decider, right?

I'm not doing this to be argumentative jk, honest, but I can't agree with you on the second point here either. There are plenty of audiophiles (hope we are not classifying them as abnormal) who have no computer knowledge or desire to mess around with such things, but expect their expensive new dac to work optimally on USB or spdif.
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.
 
Richard,

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...

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.
 
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.

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.
 
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?

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.
 
We can receive bit-perfect data from the other side of the world, so it seems an obvious option.
- Richard.

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.
 
Exactly! We don't yet know what the issues are.

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.
 
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.

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.
 
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.

Thanks.

How will you see our replies then ? :confused:
 
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.

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.
 
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.

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'
 
However, the secondary issues that apply to USB data transfer will potentially apply to ethernet or wifi.

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

I suppose you could also argue that it's better to keep that Ethernet/wifi subsystem out of the dac enclosure due to noise issues, but I find that a bit contradictory as it seems we are happy to stuff the thing full of fpga and DSp processing for the upcoming Minidsp functionality.

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.
 
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.

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.
 
Well ... there are other ways. How about ethernet? We can receive bit-perfect data from the other side of the world, so it seems an obvious option.

- Richard.
(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. :)

Jiri
 
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.

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
 
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.

Thanks john, that allays one of my small concerns
 
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.

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 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.

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

- Richard
 
Status
Not open for further replies.


advertisement


Back
Top