M2Tech Hiface - Why not female USB to male BNC/RCA instead?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
I know that M2Tech might watch this forum, but after seeing this:

Halide Design Bridge Review | Computer Audiophile

I'm wondering why M2Tech doesn't make a HiFace with a female USB and a male BNC or RCA. This would take care of a lot of potential jitter problems in running a cable carrying SPDIF, and cut down on overall costs because a great USB cable is less expensive than a great SPDIF cable. The USB is also arguably less likely to cause problems with jitter than an SPDIF cable.

Perhaps there would be issues with plugging a potentially heavy USB cable into a long converter attached to an RCA or BNC (probably less problems with the locking BNC).

Has anyone thought of this? I think it is a great solution, and should be easy to implement as an option. Any thoughts?

Aaron.
 
> You're missing the point. With a USB extension cable, you still need to connect the female RCA or BNC at the end of the M2Tech to the female input on the DAC. You would still need a digital cable for that, or perhaps a male to male adaptor. The idea is to eliminate the digital cable.

No reason why you cannot use a male BNC + female USB Series B at Hiface, put it literally at the BNC input of the DAC, and run a long USB cable to your PC.
Or ?


Patrick
 
> You're missing the point. With a USB extension cable, you still need to connect the female RCA or BNC at the end of the M2Tech to the female input on the DAC. You would still need a digital cable for that, or perhaps a male to male adaptor. The idea is to eliminate the digital cable.

No reason why you cannot use a male BNC + female USB Series B at Hiface, put it literally at the BNC input of the DAC, and run a long USB cable to your PC.
Or ?


Patrick

That's exactly what I am saying, why not? You could do it with adaptors, but why not make a version with this design, Female USB input, Male BNC output, then there is no digital cable, only a USB cable, which doesn't have the same issues as SPDIF. Seems to me that this should be the de facto configuration since the USB to SPDIF converters have gotten so small. Perhaps blocking an input on a DAC could happen, but I think it might be worth the hassle.

Aaron.
 
Yeah - I had the same idea.
I might be misunderstanding the way the Hiface works but I figured essentially jittery stuff goes in and unjittery stuff comes out.;)
If the device plugs into the usb out and then runs down a (sometimes) long coax cable with less then ideal connectors (RCA), there is more chance of adding jitter.
If the device is plugged direct into the DAC then you can run your length of USB cable from source and not care so much about jitter because it is pre-device.
Are we flying the same plane?
 
Yeah - I had the same idea.
I might be misunderstanding the way the Hiface works but I figured essentially jittery stuff goes in and unjittery stuff comes out.;)
If the device plugs into the usb out and then runs down a (sometimes) long coax cable with less then ideal connectors (RCA), there is more chance of adding jitter.
If the device is plugged direct into the DAC then you can run your length of USB cable from source and not care so much about jitter because it is pre-device.
Are we flying the same plane?

Exactly the same plane. Running a long USB cable, then have a female RCA or BNC to connect to the male input on the DAC seems like the best solution, without taking it apart and putting it inside the player. It also saves money on a digital cable, since USB cables are inexpensive and effective at what they do. I am far from an expert, but I can't see a reason not to do it this way, and I'm wondering if the M2Tech folks have considered this.

Aaron.
 
bridge.png


Prayers answered.

But @ $450, I'll need another prayer. One that makes me rich.

Halide Design - Bridge USB to S/PDIF converter
 
Pretty sure that isn't the whole story. How is clocking handled over USB?

I went digging and all I've found so far is this paper from USB.org

http://www.usb.org/developers/devclass_docs/audio10.pdf

On Page 19:-

<QUOTE>
By following these rules, phase jitter is limited to​
±1 audio sample. It is up to the host software to
synchronize the different audio streams by scheduling the correct packets at the correct moment, taking

into account the internal delays of all audio functions involved.
</QUOTE>

and I dug back into the original "Bits is Bits" paper (thank you for the tip Rich, lots of other good stuff on that site too ;-)

http://www.essex.ac.uk/csee/research/audio_lab/malcolmspubdocs/G33 Bits is bits.pdf

Looking at the above the argument centers around SP/DIF & AES being a bandwidth limited transfer medium. There are a myriad of other factors that can cause issues too, including RF noise getting into the signal further messing up clock recovery which might be the case in other discussions about modding the Hi-Face.

As for avoiding an SP/DIF cable in favor of a longer USB cable I really can't see the benefit in most cases. Once you have an SP/DIF link then as long as you don't have incorrect or overly long cabling then capacitive effects, reflections etc should be well below the level that would cause issues greater than are inherent in the underlying signal and the way the receiving end processes it.

There's the "Bits is Bits" discussion, but in this case I think it's fair to say that there's not much room to debate "Electrons is Electrons".

Particularly when the limitations of SP/DIF and AES are orders of magnitude lower than that inherent in USB audio.

Any thoughts on this, I'm still trying to get a solid grip on the subject but I think my argument is sound. What am I missing?


 
I do not see the order of magnitude higher limitations of asynchronous usb audio (finally being deployed these days) compared to SPDIF. Asynchronous usb audio has master clock on the receiving end and the transmitting one is fully slaved. No software can have any influence, apart of non-delivery which can happen in PCI/FW solutions too.

SPDIF must recover the clock on the receiving side.

Honestly, I do not see any technical point in USB/SPDIF converter. An asynchronous USB receiver right next to the DAC would make much more sense to me. But that is rather offtopic to this thread.
 
Have you read the papers I linked earlier?

Reading them, it looks to me that USB has a potential jitter window of 1 sample (44.1ms @ CD rates), SP/DIF is usually MUCH lower (8-180ns) before clock recovery. There's at least an order of magnitude in that delta.

Clock recovery isn't perfect for SP/DIF for reasons outlines in Prof. Omar's paper, but in and of itself the SP/DIF spec is capable of performing at a level that means errors are inaudible.

The point I'm trying to make is this (And directly on topic):-

If you are going to have a USB <> SP/DIF interface then I'm pretty certain that (unless you have poor RF/noise supression or poor cable) there will be no improvement by going from:-

4ft of 75Ohm co-ax on the SP/DIF side and 1ft of USB cable.

to

Just a BNC and some PCB traces on the SP/DIF side and 5ft of USB cable

In both cases you have SP/DIF and USB in the path, how long (within reason) each cable is should make zero difference.

"Elecrons is Electrons" regardless of the "Bits is Bits" debate.
 
Reading them, it looks to me that USB has a potential jitter window of 1 sample (44.1ms @ CD rates), SP/DIF is usually MUCH lower (8-180ns) before clock recovery. There's at least an order of magnitude in that delta.

Sorry, but I do not understand your conclusion. IMO the quoted text deals with synchronizing multiple audio streams transfered over USB, respectively variations in the their mutual shift one to each other - i.e. the phase jitter. Time jitter of properly designed asynchronous USB interface is equal to the jitter of its crystal clock next to the receiver, it is a truly master/slave protocol. The receiving side has a small buffer and based on its status it tells the transmitting side to keep sending more or fewer samples each frame, i.e. each 1ms. IIRC the protocol specifies the feedback value contains number of samples the transmitter should send in the next frame. Data are read from the buffer by precise stable no-PLLed clock.
 
My reading of that was phase jitter between any two channels is +/- 1 sample. AFAIK Stereo is considered as two channels, hence my statement. Am I wrong? I was asking if someone had comment as I'm still trying to get a grip on the subtlties. :)

I'm pretty sure that my original point still stands regardless of USB jitter questions.

Unless someone can clearly explain why not:-

In general, Long USB <-> Short SP/DIF or Short USB <-> Long SP/DIF should make no difference (Assuming no other "specific" factors are at play) as you're stuck with the deficiencies of both.
 
My reading of that was phase jitter between any two channels is +/- 1 sample. AFAIK Stereo is considered as two channels, hence my statement. Am I wrong? I was asking if someone had comment as I'm still trying to get a grip on the subtlties. :)

I just told you how asynchronous USB audio works. Do you see there any room for time difference of 1 sample (thus 41 audio samples)? IMO what the document means is that same-time sample for the next channel can come in the next frame, which of course makes sense for packet-based transmission. Unless the driver authors keep the same-time samples for various channels in the same frame. We can check linux usb audio source code but I would assume that is what they do. Separating the samples would be kind of weird, IMO.

Still this is about the transmission. The final jitter is at the output of the buffer where all the samples are propetly lined-up.

I have been talking about asynchrounous (not adaptive) USB audio on purpose as I believe it is the proper way to go in the future. I think all existing USB audio v.2 use asynchronous audio now.

I'm pretty sure that my original point still stands regardless of USB jitter questions.

I never disputed the length of cables. IMO no SPDIF should be employed in the first place when running USB, as usb adaptive is basically similar to SPDIF (why stacking two deficient technologies on top of each other?) and USB asynchronous can replace SPDIF easily.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.