lejonklou wrote:
It's easy to jump to that conclusion, but there are challenges with all digital systems. The problems associated with USB are very similar.
Before we start looking outside of science, and logic, I'm sure there are more stones to be turned inside.
That Linnofils lightbuls affects his sound, I'm sure that can be explained by science and noise beeing refed into the powerline. But you can't have ripples in a bitperfect stream. Because then it's not bit-perfect any more. This is easy to check with checksums or hashes, If it's not electrical interference from the NAS, it is data-loss somewhere. I think data integrity is a big problem.
The problem with USB dac's is that they start a PCM stream at the motherboard, and then tries to preserve that stream all the way to the dac. Which is impossible, when using the unstable streamer capability of usb.
Synchronous dac's, tries to slave the dac clock to the motherboard clock.
Classical asynchronous dac's tries to slave the motherboard clock to the dac masterclock. That clock can't follow very good.
Therefore, any good sounding usb-dac, needs to use a file transfer protocol, before starting any clock.
I don't know if that has been implemented correctly by HRT, HENRY and Cambridge.
If they are starting, a PCM stream at the computer, then they are not bit perfect, since there is clock information being sent in/with the stream.
This is why I still think an USB dac can be made to sound better than a Klimax DS.
Already done. Works better but doesn't solve all problems. And using a custom protocol can result in massive amounts of work, trying to keep it bug free and working with lots of hardware.
I guess most NAS'es support FTP, and that can be used?
What the software can do is, connecting to the ftp, create a hash of the file before starting to load it over and after the transfer, create a new hash. But I don't think this should be needed, since ftp already is using TCP/ip. And TCP/IP = bit perfect.
Number one we did. Unfortunately, the design with requesting the data from a NAS, passing a switch, sounds better. I think a solution could be to design the hardware in-house in much greater detail, tuning every parameter for optimal musicality. But this is too big an undertaking. I know a guy who can write his own machine code for how a processor reads, writes and shuffles data from memory chips. But that would rule out a lot of standard components and become extremely specialised. It would be like designing your own computer from scratch. Very complicated and risky. Technology moves so fast and parts are being discontinued in a matter of months.
Here questions must be asked. Why does it sound better streaming the data. It probably has to do with the design of the post-transfer pre-dac hardware/software and not the the choice of solution.
But I would much rather see a streaming solution over a file transfer protocol, if possible, than a downloading solution that takes forever:D
Number two I don't quite understand. It sounds like a standard solution with a very small buffer to me? There is to my knowledge nothing that is "100% free of any timing (issues/inaccuracies)". There is nothing that's perfect, digital signals all have an analogue representation and as such are never perfect.
I'm stil not sure how uPNP does it. It seems to create a stream with RTSP and transfer it with RTP at the NAS, which is a real-time streaming, time stamping protcol without recovery of lost packets. Than it's not bitperfect in other words. But some linn links, seeem to sugest uPNP uses tcp/ip. I'm not sure. Maybe it's rtp inside of tcp/ip:D
But what I meant here, was to use a filetransferprotcol(tcp/ip), to fill arrays byte by byte, for every packet that has been received. This prevents any clocking to start, that i suspect RTSP/RTP do. And since TCP/IP asssures packets to be recived in the right orders, I suspect this would be an error free way of doing streaming.
I just found this on the internet. RAAT. Have you looked into it? It requires no codec supports on the dac-side
and it doesn't allow a clock to be started on the source.
If Spotify and others implement this into their PC-software. PC is going to be gold again!
Unfortunately, both Airplay and Songcast have two fundamental problems related to sound quality. One is limited format support (no DSD) and that the clock is driven by the source, instead of the receiver (the endpoint surely will have the best crystal in the room).
We plan to solve these problems with the Roon Advanced Audio Transport (RAAT) protocol. The 20+ manufacturers we’ve spoken to, including Bel Canto that you mention, are loving our solution. It puts the audio in their hands, and the experience control in ours. It compromises nothing for quality, and puts very little burden on the manufacturer. It also allows for expansion, while never creating a lowest common denominator experience.
I really appreciate your ideas, many thanks!
Thank you I really appreciate you to allow me to express them, even though I'm sure I could be reading up more on things before writing.