[ZappaMan]

I agree with Nick above. My opinion is that it’s the overlaid electrical noise and RFI that can be transmitted from component to component that weneed to be concerned with. The data files are perfectly (bit perfectly) fine. If real time processing of stored files was an issurpe for music or anything, we would have random errors occurring every time we opened an excel or word doc, which we do not.

Ok, maybe got sidetracked into a particular detail that I’m no expert in. The main point was, bit perfect playback does not mean that the dac receives the signal identically; that there is more at play.
Everyone’s opinions are welcome obviously.
The main thing I’ve picked up from looking at the audio usb protocol is that it is not the same protocol as transferring files. It’s a real time protocol with limit error correction.
So when well meaning arm chair audio protocol Experts (just kidding) make comparisons to - why doesn’t my word doc fail to open properly every time, then they have went astray at the first gate.

 

[jarnopp]

Ok, maybe got sidetracked into a particular detail that I’m no expert in. The main point was, bit perfect playback does not mean that the dac receives the signal identically; that there is more at play.
Everyone’s opinions are welcome obviously.
The main thing I’ve picked up from looking at the audio usb protocol is that it is not the same protocol as transferring files. It’s a real time protocol with limit error correction.
So when well meaning arm chair audio protocol Experts (just kidding) make comparisons to - why doesn’t my word doc open openly every time, then they have went astray at the first gate.

I am here to learn too. We know there can be compromises, like with Bluetoooth or other protocols. That’s why I like Roon when I can (https://kb.roonlabs.com/RAAT), but don’t know about DLNA or Airplay (assuming Airplay is getting a sample rate it doesn’t need to resample).

 

[AndrewOld]

Made up numbers because I’m just having a casual conversation. Andrew, you’ve upset me lol, I thought we were on the same team.

Sorry I upset you, I upset most people. But it upsets me too when people propound theories based on incorrect premises. There’s no reason why digital sources should sound the same, but whatever the reason they sound different, if they do, is nothing to do with data loss. I also object to the way the reviewer trashed the Hugo 2. It doesn’t ruin songs.

 

[dontfeedphils]

I also object to the way the reviewer trashed the Hugo 2. It doesn’t ruin songs.

He said comparatively, he wasn't trashing it. Also, hearing how a song can sound through a proper source when directly compared to a noisy source I'm inclined to agree.

Plus it's his subjective opinion, why should it bother you?

 

[ZappaMan]

Sorry I upset you, I upset most people. But it upsets me too when people propound theories based on incorrect premises. There’s no reason why digital sources should sound the same, but whatever the reason they sound different, if they do, is nothing to do with data loss. I also object to the way the reviewer trashed the Hugo 2. It doesn’t ruin songs.

It’s a fact that under the usb audio protocol data packets are dropped. It must follow that without the data, the full bit perfect music cannot be recreated. It may not be a big problem but it is a fact.

quote:
3. Isochronous Transfers

Isochronous Transfer is used where data delivery at constant rate is important even if some data gets missed or corrupted. Guaranteed bandwidth is there for Isochronous Transfer but there is no guarantee for error free delivery. They are typically used to transmit time-sensitive information, like audio or video. There should not be any delay in data transmission for real time audio or video streaming; else it will result in glitches at output.

 

[Triode User]

It’s a fact that under the usb audio protocol data packets are dropped. It must follow that without the data, the full bit perfect music cannot be recreated. It may not be a big problem but it is a fact.

quote:
3. Isochronous Transfers

Isochronous Transfer is used where data delivery at constant rate is important even if some data gets missed or corrupted. Guaranteed bandwidth is there for Isochronous Transfer but there is no guarantee for error free delivery. They are typically used to transmit time-sensitive information, like audio or video. There should not be any delay in data transmission for real time audio or video streaming; else it will result in glitches at output.

I’m still not sure your quoted ‘fact’ is a fact. I refer you back to the implication of missing or corrupted date which Rob says (many times) will create a pop or crackle and that just doesn’t happen in reality.

 

[miketlse]

Also the chord usb drivers, request corrupted data is resent.

 

[guerph]

Interestingly, moon-audio is showing these in stock as of today. Wow.

 

[ZappaMan]

I’m still not sure your quoted ‘fact’ is a fact. I refer you back to the implication of missing or corrupted date which Rob says (many times) will create a pop or crackle and that just doesn’t happen in reality.

I refer you back to the fact that the protocol does not guarantee delivery ..... fact.

 

[ZappaMan]

Also the chord usb drivers, request corrupted data is resent.

Exactly, data gets corrupted in certain scenarios and needs to be corrected.

 

[Triode User]

I refer you back to the fact that the protocol does not guarantee delivery ..... fact.

Hopefully someone who knows what they are talking about (@Rob Watts ) might be along to sort this out and say whether corrupted data or missing data happens. I suspect that in reality it doesn’t happen.

 

[ZappaMan]

Hopefully someone who knows what they are talking about (@Rob Watts ) might be along to sort this out and say whether corrupted data or missing data happens. I suspect that in reality it doesn’t happen.

Then why did chord specifically write a driver with different error retry logic (only applicable on windows). It’s ok to be wrong nick, we are all wrong at times. Today it’s your turn to bang at the open door

 

[Triode User]

Then why did chord specifically write a driver with different error retry logic (only applicable on windows). It’s ok to be wrong nick, we are all wrong at times. Today it’s your turn to bang at the open door

I’m a Mac guy so can’t help with the open door.

 

[AndrewOld]

Boys and girls, let’s do some simple sums. Too big for your fingers, but I’ll show my workings.
44,100 samples of 16 bits every second is 705,600 bits
Times 2 because it is stereo we are talking about is 1,411,200 bits a second
Times 60 for bits a minute is 84,672,000 bits a minute
Times 60 for bits an hour is 5,080,320,000 bits an hour. Let’s call that 5000 million bits an hour.
The Bit Error Rate quoted in the paper I linked to earlier is 1 in 10^12 bits. 1 in 1 million million
So, 1 million million divided by 5000 million is 200.
So that’s a potential error of 1 bit every 200 hours,
So, if you listen for 5 hours a day you might, might, get a 1 bit error every 40 days.
Is this a problem? Seriously?

 

[ZappaMan]

Boys and girls, let’s do some simple sums. Too big for your fingers, but I’ll show my workings.
44,100 samples of 16 bits every second is 705,600 bits
Times 2 because it is stereo we are talking about is 1,411,200 bits a second
Times 60 for bits a minute is 84,672,000 bits a minute
Times 60 for bits an hour is 5,080,320,000 bits an hour. Let’s call that 5000 million bits an hour.
The Bit Error Rate quoted in the paper I linked to earlier is 1 in 10^12 bits. 1 in 1 million million
So, 1 million million divided by 5000 million is 200.
So that’s a potential error of 1 bit every 200 hours,
So, if you listen for 5 hours a day you might, might, get a 1 bit error every 40 days.
Is this a problem? Seriously?

I’m open minded, really. I wonder why chord made the driver.
I looked at your quoted article for usb and it says.
“Isochronous transfer – used to stream data but packets can be “lost”. Used for streaming video and audio. In this case, packets can be dropped often because the next frame of video or audio must be delivered to keep streaming. In this case no retries are attempted. This means that lots of BER will mean terrible streaming of the video for incomplete or bad pictures and or poor audio.”

a non specialised source like a pc has real time issues because it has a lot of other demands on its resources. As it’s hits a peak load, maybe then it’s more prone to not keep up it’s commitments to it’s downstream components.