[Currawong]

Sorry, I should have been specific. I was referring to the input of the Hugo 2 only. For that, what you linked to will work. I use a 3.5mm stereo to dual-RCA adaptor, which allows both coaxial inputs, simply because I have them on hand.

The M9 requires a FiiO-specific cable, as Relic described, such as the one included in the box. They can sometimes can be found elsewhere. I built my own, so I haven't specifically looked online for them.

 

[Vampa]

Sorry, I should have been specific. I was referring to the input of the Hugo 2 only. For that, what you linked to will work. I use a 3.5mm stereo to dual-RCA adaptor, which allows both coaxial inputs, simply because I have them on hand.

The M9 requires a FiiO-specific cable, as Relic described, such as the one included in the box. They can sometimes can be found elsewhere. I built my own, so I haven't specifically looked online for them.

Got it now, thanks! have ordered the adapter.

 

[Andyb90]

I just got an Audioquest Carbon cable and tried it with the Hugo2 for 192Khz playback. It doesn't work. The cable doesn't work with the Mojo either.

The toslink cable that came with the Hugo2 works with the Mojo for 192Khz. I tried it again with the Hugo2. Surprisingly it worked with 192Khz this time. I then swapped the ends of the cable so the opposite end was connecting to the Hugo2 and it no longer works.

So I'm a bit confused about where the problem is. I've got another cable on the way to try out, but I'm wondering if toslink just isn't that reliable for 192Khz. Both cables work fine with 96Khz playback for the Hugo2 and Mojo.

 

[miketlse]

I just got an Audioquest Carbon cable and tried it with the Hugo2 for 192Khz playback. It doesn't work. The cable doesn't work with the Mojo either.

The toslink cable that came with the Hugo2 works with the Mojo for 192Khz. I tried it again with the Hugo2. Surprisingly it worked with 192Khz this time. I then swapped the ends of the cable so the opposite end was connecting to the Hugo2 and it no longer works.

So I'm a bit confused about where the problem is. I've got another cable on the way to try out, but I'm wondering if toslink just isn't that reliable for 192Khz. Both cables work fine with 96Khz playback for the Hugo2 and Mojo.

The FAQ in post #3 of the Mojo thread contains some info about optical cables, including a link to this post containing generic info.

 

[Andyb90]

Just got a second cable QED Reference Optical Quartz. I've tried a couple of 192Khz tracks and both played with the Hugo2. Sample light is Blue. So this one looks promising. Hopefully it will be consistent, but I'll get a coax cable as backup in case I have further problems. I've just noticed there are now some new Atlas cables available in the UK with 3.5mm connector.

 

[flyte3333]

I was told by Chord that the Windows driver re-sent error data; I presume this must apply to ASIO as well.

Hi @Rob Watts - Happy Holidays and Happy New Year to you!

Regarding what I've quoted here from the Blu2 thread - are you able to confirm that the same applies to both WASAPI and ASIO driver?

Or does this only apply to the WASAPI driver?

Can you kindly check with Chord and confirm here?

Cheers!

 

[flyte3333]

It's true that standard driverless USB does not resend faulty packets; but with the Chord Windows driver, it does.

I was told by Chord that the Windows driver re-sent error data; I presume this must apply to ASIO as well.

Hi @Matt Bartlett

Regarding the above quotes from @Rob Watts :

Is it only the Chord WASAPI driver in Windows that re-sends faulty USB packets to Hugo2?

Or do both the Chord WASAPI and Chord ASIO Windows drivers have this feature?

Cheers

 

[Matt Bartlett]

Hi @Matt Bartlett

Regarding the above quotes from @Rob Watts :

Is it only the Chord WASAPI driver in Windows that re-sends faulty USB packets to Hugo2?

Or do both the Chord WASAPI and Chord ASIO Windows drivers have this feature?

Cheers

Yes ASIO will re-send faulty or lost USB packets as well.

 

[flyte3333]

Yes ASIO will re-send faulty or lost USB packets as well.

Thanks Matt!

And Chord's Windows WASAPI driver will re-send faulty / lost USB packets too?

 

[Matt Bartlett]

Thanks Matt!

And Chord's Windows WASAPI driver will re-send faulty / lost USB packets too?

Yes WASAPI, Kernel Streaming and ASIO all work in the same way to resend lost packets.

 

[flyte3333]

Yes WASAPI, Kernel Streaming and ASIO all work in the same way to resend lost packets.

Thanks Matt. I haven't seen too many manufacturers that have this feature with their USB DACs. Very cool indeed.

 

[flyte3333]

Yes WASAPI, Kernel Streaming and ASIO all work in the same way to resend lost packets.

Hi @Matt Bartlett

@john57 mentioned in another thread:

"That would not make any sense to resend any audio packets when music is playing in real time. With Data it does not mater and even packets could be a little bit out of order when reached the destination where it is put together in order."

Can you share some more info on how this re-sending of dropped/lost USB audio packets works in real-time music playback? When used with Chord's Windows driver.

Cheers!

PS: note (before anyone asks)... I'm not at all concerned about dropped USB Audio packets. I'm just really interested in how this works because it's not that common.

 

[Matt Bartlett]

Hi @Matt Bartlett

@john57 mentioned in another thread:

"That would not make any sense to resend any audio packets when music is playing in real time. With Data it does not mater and even packets could be a little bit out of order when reached the destination where it is put together in order."

Can you share some more info on how this re-sending of dropped/lost USB audio packets works in real-time music playback? When used with Chord's Windows driver.

Cheers!

PS: note (before anyone asks)... I'm not at all concerned about dropped USB Audio packets. I'm just really interested in how this works because it's not that common.

I think the key here is that yes the music might be playing in real time but the digital audio data transmission is sent at a faster rate. The process is relatively simple where the data is sent, buffered and error checked. If there is a problem then the data can be retransmitted before it is required to keep the music playing. I can't give out many more details than this as it is proprietary technology and I need to keep some parts of the process confidential - I hope you understand.

 

[flyte3333]

I think the key here is that yes the music might be playing in real time but the digital audio data transmission is sent at a faster rate. The process is relatively simple where the data is sent, buffered and error checked. If there is a problem then the data can be retransmitted before it is required to keep the music playing. I can't give out many more details than this as it is proprietary technology and I need to keep some parts of the process confidential - I hope you understand.

Thanks Matt. I figured it was all to do with a buffer which allows for a certain/limited number of re-tries, for any dropped/lost packets.

 

[musickid]

i always thought this was universal usb protocol and not manufacturer specific?