Perceived SQ differences playing local files

[Tim Curtis]

My observation is that SQ discussions often get derailed by posts asserting that its just placebo effect or some other tricking of the mind. Thats a valid point of view but rarely do these types of posts just leave it at that. They typically wade into the swampy area of rudeness, misinformation, trolling, insults and so on. Not good.

[Jandu]

Another easy thing to do which may improve your SQ:

1, if using a USB C connection for Power supply, try to insert it the other way.
2, if you can connect your power supply to the GPIO pin and bypass the USB C connection, it may help as well. This is assuming that you are using a good LPS. By the way this will cause damage to your RPi, if your have power spikes, since it bypass the safe guards of the RPi.

Have fun!

[bodiebill]

Thanks @Jandu for the the 2 recommendations. I will look into the Compact Flash one. The power one does not apply to my setup as I am already powering the RPi and Pi2AES with DC not using the usb input.

I am sometimes amazed by the oversimplifications used by bitperfectionists. Are they lacking a dimension? Does the time domain not exist for them? Oh well, we can agree to live on different planets.

Even though a mathematician I have always been a subjectivist as regards audio -- convinced that we hardly know anything. Clinging to a few simplistic rationalizations that we confuse with 'understanding', severely limits our ability to lucidly perceive and experience sound (or maybe only works for people not having good hearing to begin with). I believe that my sensory system and intuition are -- at least in this domain -- much more powerful tools than my flawed ratio.

Sorry, I just had a nice Belgian beer...

[Tim Curtis]

Yes apparantly not enought time to mention Time. Even less likely is a mention of the transfer method used after the bits leave the safe haven of the file/stream reader :-0

[the_bertrum]

Yes apparantly not enought time to mention Time. Even less likely is a mention of the transfer method used after the bits leave the safe haven of the file/stream reader :-0

In conversations of this type, I always wish to know the "why" of it. There is plenty of "why" to explain how accurate timing is important in conversion and transport after the safe haven, but I've yet to ever hear a "why" for how the information in a file can be corrupted in specific detectable but non-destructive ways by things like plugging a USB cable in the other way before it leaves that safe haven. For some, that they hear a difference is enough never mind the why, for me I always want to know why.

[Tim Curtis]

Yes apparantly not enought time to mention Time. Even less likely is a mention of the transfer method used after the bits leave the safe haven of the file/stream reader :-0

In conversations of this type, I always wish to know the "why" of it.  There is plenty of "why" to explain how accurate timing is important in conversion and transport after the safe haven, but I've yet to ever hear a "why" for how the information in a file can be corrupted in specific detectable but non-destructive ways by things like plugging a USB cable in the other way before it leaves that safe haven.  For some, that they hear a difference is enough never mind the why, for me I always want to know why.

Timing jitter is effectively handled by audio devices that operate as bus masters and "pull" the audio data from the host and then re-clock it using onboard precision clocks. Devices connected via the I2S bus become bus master by setting up whats called I2S Master Mode. Devices that connect via the USB bus become bus master by setting up whats called USB Asynchronous Transfer Mode. There are also dedicated re-clocking devices that sit inbetween the host and the audio device.

Corruption of digital signals transmitted within a system occurs by the usual suspects including electrical noise, implementation bugs, resource congestion/starvation, etc. The specific causes depend on the transmission medium and method of transmission. Types of corruption include bit errors, dropped packets, out of sequence packets and so on.

Recognising this the implementation of many digital communication protocols for example TCP/IP include robust error detection, correction and retransmission mechanisms to ensure data integrity. File transfer, downloading files Web browsing, Email and many other types of bulk data transfer use these robust mechanisms because their purpose is to guarantee error free delivery of the data. There are no timing or data rate constraints with these types of protocols.

Some communication protocols for example USB Isochronous Transfer Mode or I2S bus serial transfer however have no such data integrity mechanisms because their purpose is to deliver data in real-time at a specific constant rate and under strict timing constraints. The reason there is no data integrity mechanism is that the time it takes (overhead) to perform these operations exceeds the rate and timing constraints. In these protocols regardless of the integrity of the data its simply passed on to the end point.

Audio data that is to be transmitted in real-time for example between a host and a USB attached audio device will use Isochronous Transfer Mode. If the audio device is attached to the I2S bus for example a Pi HAT audio board it will be using I2S serial transfer protocol.

To determine the integrity of the data being transmitted across USB or I2S busses its necessary to connect a bus protocol analyzer between the host and the device that can capture the data in real-time and provide an intelligent analysis showing any data, sequence or other errors.

Links
https://www.xmos.ai/download/Fundamental...o(1.0).pdf
https://en.wikipedia.org/wiki/I²S
https://www.totalphase.com/blog/2020/07/...hoot-them/
https://www.totalphase.com/solutions/wp/debugging-usb/

[Jandu]

Yes apparantly not enought time to mention Time. Even less likely is a mention of the transfer method used after the bits leave the safe haven of the file/stream reader :-0

....things like plugging a USB cable in the other way before it leaves that safe haven.  For some, that they hear a difference is enough never mind the why, for me I always want to know why.

Not that I don't want to provide the reasons, just that it is environment, system, music and hearing dependent. Based on all these factors that could affect its results, it is better/easier just to try.

Environment dependent - how dirty is your 5v conversion from your house power supply, this also depends on your house power supply
System - whether the system can provide the resolution to make a difference
Music - may require a hi-res version of soundtrack, instead of low quality such as MP3, to appreciate the difference

According to the source that I have read, most if not all, computing devices use a clock somewhere. The power supply affects how stable the power to the clock and affects the operation of the clock. The USB C, which can be use upside down, has the correct polarity in only one way. When you are using the right polarity without having the RPi to invert the polarity, the power supply would be that much better/cleaner to the clock. The better power supply to the clock, the more accurate the clock would be. 

Here is a link to a pic which shows someone, on a RPi audiophile forum, changes the clock on a CF card reader to further upgrade its clock to use a TCXO clock to improve the performance of the CF card reader. 

http://www.stsd99.com/phpBB3/viewtopic.p...7&start=40

However, the fastest way to check if you can gain benefit from the trick is to just try it and report back.

[the_bertrum]

Yes apparantly not enought time to mention Time. Even less likely is a mention of the transfer method used after the bits leave the safe haven of the file/stream reader :-0

In conversations of this type, I always wish to know the "why" of it.  There is plenty of "why" to explain how accurate timing is important in conversion and transport after the safe haven, but I've yet to ever hear a "why" for how the information in a file can be corrupted in specific detectable but non-destructive ways by things like plugging a USB cable in the other way before it leaves that safe haven.  For some, that they hear a difference is enough never mind the why, for me I always want to know why.

Timing jitter is effectively handled by audio devices that operate as bus masters and "pull" the audio data from the host and then re-clock it using onboard precision clocks. Devices connected via the I2S bus become bus master by setting up whats called I2S Master Mode. Devices that connect via the USB bus become bus master by setting up whats called USB Asynchronous Transfer Mode. There are also dedicated re-clocking devices that sit inbetween the host and the audio device.

Corruption of digital signals transmitted within a system occurs by the usual suspects including electrical noise, implementation bugs, resource congestion/starvation, etc. The specific causes depend on the transmission medium and method of transmission. Types of corruption include bit errors, dropped packets, out of sequence packets and so on.

Recognising this the implementation of many digital communication protocols for example TCP/IP include robust error detection, correction and retransmission mechanisms to ensure data integrity. File transfer, downloading files Web browsing, Email and many other types of bulk data transfer use these robust mechanisms because their purpose is to guarantee error free delivery of the data. There are no timing or data rate constraints with these types of protocols.

Some communication protocols for example USB Isochronous Transfer Mode or I2S bus serial transfer however have no such data integrity mechanisms because their purpose is to deliver data in real-time at a specific constant rate and under strict timing constraints. The reason there is no data integrity mechanism is that the time it takes (overhead) to perform these operations exceeds the rate and timing constraints. In these protocols regardless of the integrity of the data its simply passed on to the end point.

Audio data that is to be transmitted in real-time for example between a host and a USB attached audio device will use Isochronous Transfer Mode. If the audio device is attached to the I2S bus for example a Pi HAT audio board it will be using I2S serial transfer protocol.

To determine the integrity of the data being transmitted across USB or I2S busses its necessary to connect a bus protocol analyzer between the host and the device that can capture the data in real-time and provide an intelligent analysis showing any data, sequence or other errors.

Links
https://www.xmos.ai/download/Fundamental...o(1.0).pdf
https://en.wikipedia.org/wiki/I²S
https://www.totalphase.com/blog/2020/07/...hoot-them/
https://www.totalphase.com/solutions/wp/debugging-usb/

Thanks for the links Tim, very useful insights.  Are the files generally read from storage over these low/no integrity methods , i.e. "streamed from disc" or do the file reads happen over an error corrected method into memory and streamed from there?
I'm wondering if the general principle that SQ is improved in these low integrity situations by using methods that result in the accumulation of fewer errors over time, or perhaps that the compensation applied in some methods is better than others?

[Tim Curtis]

Files are read from storage and transferred to host memory buffers using bulk data transfer protocols and thus with data integrity. The buffers are then read and transmitted to the audio device over USB or I2S connections using either Isochronous Transfer Mode or I2S serial transfer and thus with best effort delivery and no error correction or retransmission.

Streaming media protocols are a bit different and are designed for low overhead data transmission between hosts over a network connection. Small amounts of packet loss, packet sequence errors and and data corruption are expected and can to a degree be compensated for using various methods. Typically Real-time Transport Protocol (RTP) is used over a User Datagram Protocol (UDP) transport. UDP doesn't provide any error correction or retransmission but RTP does provide some amount of data integrity, timing and delivery handling.

moOde's Multiroom Audio feature is based on an RTP/UDP stack.

Links
https://en.wikipedia.org/wiki/Real-time_...t_Protocol
https://en.wikipedia.org/wiki/User_Datagram_Protocol

[yannig]

My observation is that SQ discussions often get derailed by posts asserting that its just placebo effect or some other tricking of the mind. Thats a valid point of view but rarely do these types of posts just leave it at that. They typically wade into the swampy area of rudeness, misinformation, trolling, insults and so on. Not good.

Beyond a certain number of comparisons, no placebo effect remains.

But so few people know this in audio.
Which I find strange.