[flyte3333]

I like HQPlayer but I haven't found a good frontend solution for it item than Room.

Roon is better but you can play from Audirvana direct to HQP Embedded server (not to HQP Desktop). Then you have HQP Embedded server playing to whatever NAA you want. So Audirvana acts as the front-end here.

The Roon integration is much slicker though.

 

[gordec]

Of course it does... just like micro iDSD.... you can use a 3.5mm TOSlink (mini-TOSLink) cable inside the digital coax RCA connector....

Wow, thanks. Didn't know it's a combo rca/ mini toslink port.

 

[iFi audio]

Wow, thanks. Didn't know it's a combo rca/ mini toslink port.

Yup, it is!

And since 2019 is here:

https://tidal.com/playlist/aee6099a-20ba-4560-9f40-d4b595ced8a6

 

[flyte3333]

Hi @iFi audio

Does iFi's Windows ASIO driver resend faulty USB packets?

Cheers

 

[iFi audio]

Hi @iFi audio

Does iFi's Windows ASIO driver resend faulty USB packets?

Cheers

Can you elaborate please and describe what do you mean by 'faulty packets'?

 

[flyte3333]

Can you elaborate please and describe what do you mean by 'faulty packets'?

Apologies - resending dropped / lost USB packets.

Speaking of the iFi Windows driver specifically.

 

[iFi audio]

Apologies - resending dropped / lost USB packets.

Speaking of the iFi Windows driver specifically.

USB audio class 2 has no mechanism to do that.

 

[iFi audio]

Folks, MQA + Pro iDSD setup guide. It's actually valid for all MQA decoding DACs.

 

[flyte3333]

USB audio class 2 has no mechanism to do that.

Chord’s Windows driver allows this..

I don't bring Chord up for some kind of p!ssing contest by the way (not my style).

I was just genuinely interested if iFi's Windows driver (not standard driverless USB) works this way.

And I'm not at all concerned about dropped USB packets - just a technical query. Nothing more.

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

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

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

 

[john57]

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.
How DAC handles missing or bad audio information vary from each manufacture.

 

[flyte3333]

That would not make any sense to resend any audio packets when music is playing in real time.

That's what Rob Watts and Chord's Engineering/Manufacturing Director (Matt) are saying... specifically with their Windows driver... not standard driverless USB.

See below quotes... I'll ask Matt for more info on how this works.

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

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

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

mansr over on CA Forum has commented before that it is possible (not talking about any product specifically):

"If they use a custom protocol (not UAC), they could have some form of error correction"

https://audiophilestyle.com/forums/topic/54909-usb-audio-transmission-isn’t-bit-true/?do=findComment&comment=900867

Just to re-iterate in case anyone brings it up... I'm not at all concerned about dropped USB packets - just a technical query here.

 

[john57]

Error correction is not the same as re-transmitting packets. You could add error correction bits to the USB packet using a custom driver that could help the receiving end to reconstruct corrupted packets but will not help if the packet is lost. I am more concerned with DAC's receiving data that it did not understand. Some DAC's will click or pop, some will mute and some will send a burst of noise that could do damage.

 

[flyte3333]

Error correction is not the same as re-transmitting packets.

My original question to iFi is about re-sending of lost packets (using the iFi Windows driver) - based on Chord's comments about their Windows driver re-resending of lost packets (their words quoted above, not mine). So that's what I'm trying to understand - how they do that.

I imagine it's something to do with a buffer of certain size to allow for a limited number of re-tries? I asked Chord in the other thread. Will wait for their response.

 

[peterjgross]

i received my Pro iDSD today. I connected it to the network via wired connection (WiFi is not set up). Most things work fine. I could see the device from Muzo or from my DLNA control app (8player, DLNA server is whatever Netgear is using).
However, when i stream Tidal MQA from my iPhone using the Muzo app Pro iDSD tells me it processes PCM.
So, first question is - how do i check which firmware version i have?

I have read a number of posts in this forum - from that i understand that it is necessary to have firmware release 2. I also have seen that people were streaming MQA successfully using other apps than Muzo.
Last i am aware that iFi posted a video that shows that the iDSD process MQA from Tidal correctly. However, in the example the Tidal desktop app was used and it was configured for MQA passthrough - that option does not exist on the mobile app (i assume that the mobile app cannot decode MQA anyways).

Any advice appreciated.

 

[flyte3333]

Stereophile's review is now up:

https://www.stereophile.com/content/ifi-audio-pro-idsd-da-processorheadphone-amplifier

As previously mentioned, the subjective listening impressions are very positive.

According to JA, there are some puzzling (his words) measurements though:

https://www.stereophile.com/content/ifi-audio-pro-idsd-da-processorheadphone-amplifier-measurements

Would be great if iFi R&D can shed some light on JA's comments.