Hi Jim
I don’t think you are blunt (this time
)
If you hang around on too many audio forums too long and too often like I do, you will notice that a lot of people do experience problems with playback.
Hearing mouse movements are not uncommon. In fact if I connect my USB DAC to the same internal hub as my Bluetooth mouse, I can hear it the moment I move it.
Likewise drop-outs due to DPC latency are common.
Anti-virus software, bad Wi-Fi drivers (Vista!) hogging the system are common problems.
Mind you, USB audio is a isochronous stream so ‘soft’ real time.
We are doing audio on a multitasking system. By design the delivering of the data in time is not guaranteed. The speed of the CPU might be blistering, the buffer of the audio device is in general small so easily drained.
Here we talk about mangling the bits (CRC errors) or hogging the CPU or the PCI bus to such extend that the data flow is interrupted.
This is not uncommon and clearly audible.
I don’t call this a sound quality issue, it is a system error.
The problem starts when the bits are not mangled.
Playing from a HD or loading the track in memory first won’t alter the bits.
One uses exactly the same data.
As PCM audio is sample + sample rate, obvious we cannot explain this by the bits. They are and will remain the same.
However, audio playback is clock driven.
If you have a SPDIF out, you do have a clock driving the sample rate.
A VCXO is by design voltage controlled. You can’t rule out that spikes on the power modulate the speed of the clock.
Here we might have a plausible technical explanation why e.g. memory playback might have an impact. No I/O is less electrical activity (RFI, EMI, ripples on the power) during playback so less disturbance of the clock.
I won’t say this is true but I do argue that PCM is sample + time step by design.
Both must be right. You can’t explain PCM audio by the bits alone. You need to take the timing in account too.
However I would love to see some measurements, somebody proving that changing system load indeed affects the jitter (the timing).
In a lot of cases (killing idle system processes) I don’t see why this should be the case.
All the best
Vincent