If the developers of Jplay can hear a difference then surely they need to work a bit harder on their coding?
Printable View
If the developers of Jplay can hear a difference then surely they need to work a bit harder on their coding?
Except that I can't hear a difference. Could be their pre-conceptions? Or my hope over realityQuote:
Originally Posted by sq225917
You know something? I looked everywhere on the DAC that I am currently using, but I can't find a USB socket on it.Quote:
Originally Posted by AlexM
Do you think that USB could be the problem? Did you say you were using async USB? Might be worth trying optical or coax out from the computer (if possible) to see if the results are still the same. Although a long shot, it could be that the async software is having an effect and not transcribing the data with single bit accuracy?
It's a general thread so one should give others the chance to contribute towards the overall discussion ;).Quote:
Originally Posted by bobbasrah
Very interesting that the JPLAY developers have come to the same conclusion as me. Maybe products and software developers do have a higher sensitivity in noticing differences. It cannot be discounted.Quote:
Originally Posted by Clive
Why? So that they can also get mp3 to sound just as good as WAV?Quote:
Originally Posted by sq225917
Haha - very good :). I assumed you were talking about a DAC with a USB output. Which USB receiver do you use in your DACs?.Quote:
Originally Posted by StanleyB
I think that some DACs will react differently to jitter on frames recieved over USB depending on how they implement FIFO queues internally, and read out the buffer.
I think of it as analagous to a big bucket with a small hole in it at the bottom. As long as the bucket doesn't empty then the rate of outflow will be relatively constant. The timing of the frames arriving into the bucket isn't too critical as long as the average data rate ensures that the buffer never empties out.
I use a coax SPDIF output from the SB Touch into a Cambridge Audio CA840C. The SB Touch outputs data over SPDIF at a constant rate, regardless of what happens to the TCPIP network. In fact, if I disconnect the network cable, the buffer will play constantly for about 30 secs, so tolerance to network jitter and latency is pretty good!.
Cheers,
Alex
It this part that my experience suggests isn't so and I can't explain why. It seems that the better timing of the data arriving with several DACs I've tried, the better the sound quality. Maybe DAC-based re-clocking can only do so much - meaning data only has a narrow window within which it needs to arrive for re-clocking to be optimal.Quote:
Originally Posted by AlexM
Clive.
I wondered if you had (assuming you have more than one core) split the core loading so only audio data moves through one core and compared this configuration to loading a complete track to RAM?
Clive,
Yes I think you are right because my analagy isn't actually how most DACs work, although mine does work like this and so does the SBT that sits in front of it.
I think a lot of DACs have a very shallow FIFO buffer, and use a PLL to slave the local clock to the long term average clock of the incoming signal. One might think that if this is wandering all over the place (quite possible), then the PLL will be skewing the DAC's local clock to track this.
Higher frequency jitter spectrum on the input will be be easily fixable with a small buffer, but low frequency jitter (a few Hz) would need quite a bit more buffering to eliminate.
A digital equivilent of analogue wow? ;).
Cheers,
Alex
John, I haven't locked the audio process to a core, I would expect that to help. What works so very well with JPLAY is hib mode, this kills the rest of the computer very effectively but it's not very user friendly either!Quote:
Originally Posted by Welder
Well things seem to be moving along apace...
The desktop, laptop and the other laptop used in the tests I mentioned earlier which failed to replicate the issue were all multi-core machines for everyday use, running XP, 7 and 7 respectively.
The USB receiver Stan uses is the PCM2902 according to the website for TC-7520 if that makes any difference.
Stan, can you recollect the equipment used and how it was coupled when you noted these differences? I presume you used your own DAC when you discovered this?
It may or may not be related, but it may help flesh out the circumstance to further isolate the cause.
One other thing I forgot to mention (reported previously on issues over async b adaptive v spdif) for fullness was that we also connected my dac on usb to the optical input on my pal's DAC to see if that made any difference in the test, there was also no change in terms of the FLAC/WAV issue. There was however a qualitative difference for the better over the direct optical to his DAC which we both found surprising from a cheap chinese async DAC.
Could the issue really be as complex as the combination of player, processor and DAC implementation, perhaps even the OS?
If it helps, I can give a full rundown on my desktop and laptop where the problems do not arise?