Cogito wrote:
HAL wrote:
Also an async USB DAC interface does the data transfer timing with it's internal clock, not the PC clock.
True, but that comes into picture only after the CPU and OS allocated time slot of the music server process, and and the music server tries to send a small chunk of data to the DAC. I do not know the size of streaming chunks used in ASIO. This is the issue I am trying to emphasize. NO matter how fast the USB is, CPU/OS and other processes running in the system will mess up the timing of the data stream.
For example if I am playing a 300MB DSD128 file which lasts 6 minutes, it could be sent to DAC is thousands of small data streams.
Further more, there should not be any other device on the USB for the controller to respond immediately (key word "serial"). If a mouse, keyboard, hard disk are working on the USB bus, the USB controller will accommodate each device by allocating the time slices.
That is why jPlay takes over the entire server disabling all unnecessary processes and keyboard, mouse etc when playing the music to dedicate max possible resources to itself.
I was happy to take this off-line, but...
I don't think you understand how audio data get transferred from the PC to the DAC. As you said, the data is sent in chunks, or packets. Enough is sent in each chunk to fill the DAC's buffer and keep the DAC busy until the next chunk is sent. Since audio streams are given a high priority in an OS since audio is one of those things that has to be serviced in a timely manner or it doesn't work well, regardless of what the PC is doing otherwise it will service the audio stream. Of course there can be exceptions, but you would hear the audio drop out if there were instances where there was no data available for the DAC to convert to audio.
Audio is slow to a computer, even a low powered PC should have no problem keeping up with anything audio. Keyboard and mouse inputs are even slower, and lower priority, and will not have any effect on audio. I'm using a Core 2 duo PC in my main system. Audio is stored on another PC in the house. I control the music PC using remote desktop. This fairly low powered computer manages to fetch the music over the LAN and feed it to the USB port or sound card and at the same time provide the remote desktop host to my laptop while I move the mouse around with no issues at all.
The fact that jPlay locks up the computer while something is playing is a non-starter for me. You can't pause or stop something playing? I control the volume through the PC, it's an external analog volume control. With jPlay I would not be able to adjust the volume while something is playing?
Then JPLay is not for you.
It's a "purist" player that uses JPlay's proprietary driver to cut through the OS to deliver the signal to the DAC. You can adjust various parameters *if* you feel they improve the sound.
I have tried--mightily--to get around the fact that different programs and OS's running on different computers can produce a different sound. But it's definitely the case as far as I am able to determine. It's true, to my ears, that a basic bit perfect player using an ASIO driver on a stock W10 install will sound the same as any other basic bit perfect player on that same computer. But not all players and OS's handle the data the same way, at least as far as I can surmise.