Internal streamer (Devialet Expert) at the end of 2016

[Antoine]

Currently already streaming via Roon and wouldn't want another interface now I got used to Roon. Briliant. If I interpret it correctly the way I'm streaming now is bit perfect so I assume then that audio quality cannot be improved by using a future internal streaming method. Is that reasoned correctly?

Depends on who you ask. You must have come accross many discussions about this already, the 'bits are bits' people, "it's all in your heads when you use a proper DAC" vs. the people that do hear differences between bit perfect player software, sources etc.

Personally I'm very tired of these discussions so I don't engage in them. But just to show where I stand I'll give you the most extreme example of something that completely challenged all my beliefs: I heard a clear difference between a standard SATA cable vs. an "audiophile" one in my now decommisioned DIY music server..still can't explain it but I have already accepted that I can't explain everything. What I do accept and believe is that to have state of the art SQ in digital a lot comes down to low RFI/EMI noise, high quality power, careful separation of ground planes and using high quality low jitter/phase noise clocks. In short we need to feed the DAC's the cleanest, low jitter signal as possible but the same goes for these DAC circuits themselves.

[iamwappie]

Hahaha totally recognizable. Having a background in electronics couldn't explain a number of improvements myself either. I was at a time a total cable non believer but once demonstrated an el-cheapo cable vs a audiophile grade couldn't deny it anymore myself. Changed all cables. The digital interlink made the biggest difference much to my surprise. Also changed the power plugs by Rhodium ones... another difference...

Only explanation I have for the digital interlink difference is the jitter story. Since no protocol is used that check for proper reception of packages small error may be introduced.

But..... If the TCP protocol is used it is assured that all network packages are received correctly. Put them in a buffer in the receiving device and once full enough stream and play them. So with that reasoning I though bit perfect is bit perfect....

But people also report that changing the network cable also makes a difference in sound...There goes my TCP reasoning....

Just have to try it I'm afraid if Devialet indeed offers the hardware upgrade and internal streaming choice

[Antoine]

Same here I'm active in IT now but was originally educated to become an electrical engineer. In my system topic I've detailed all the things I've tried that a few years back would sound utterly crazy but many did work. Keeping an open mind ("a mind is a terrible thing to close") and trying things for yourself really IMHO really is the best if you're on a hunt for ultimate SQ. Enjoy!

[Jwg1749]

All fair-minded people agree that the differences they claim to hear may well be the result of the placebo effect. It seems to me that where people differ is in the conclusions they draw from this.

[Antoine]

All fair-minded people agree that for some people there's a need to understand the world around them to feel in control. These people don't like their beliefs challenged and thus reject these things. These strong biases, sometimes also fed/kept alive by academic peer pressure, prevents them from hearing any changes/trusting their senses.

Of course the above is written with a big wink but maybe does hold some truth. Anyway I believe I just said I usually don't engage in these types of discussions so don't know why I just did. I'm outta here, it's off topic anyway.

[Antoine]

Oh, one last thing. Perhaps it's a call to authority but I read a very interesting post by Rob Watts of Chord Electronics that shows that many of these things I/we hear are real, sometimes measurable, sometimes not...just wanted to share this here: http://www.head-fi.org/t/766517/chord-el...t_12577889

[Jwg1749]

All fair-minded people agree that for some people there's a need to understand the world around them to feel in control. These people don't like their beliefs challenged and thus reject these things. These strong biases, sometimes also fed/kept alive by academic peer pressure, prevents them from hearing any changes/trusting their senses.

Of course the above is written with a big wink but maybe does hold some truth. Anyway I believe I just said I usually don't engage in these types of discussions so don't know why I just did. I'm outta here, it's off topic anyway.

I'm sorry you don't want to discuss these things. I'd have liked to ask you what you mean by 'academic peer pressure' among other things. But maybe it's better this way. I'm sure we both have better things to do, in my case my academic work. 

[arcam]

But..... If the TCP protocol is used it is assured that all network packages are received correctly. Put them in a buffer in the receiving device and once full enough stream and play them. So with that reasoning I though bit perfect is bit perfect....

You don't want to use TCP for streaming (due to latency), but RTP/UDP. Retransmission is typically handled in the RTP stack. Different retransmission strategies can be put in place. For example, for video, you don't need to retransmit past frames since they would arrive past their display time. For audio, you don't want to miss any packet or else you will hear glitches.

[Antoine]

I'm sorry you don't want to discuss these things. I'd have liked to ask you what you mean by 'academic peer pressure' among other things. But maybe it's better this way. I'm sure we both have better things to do, in my case my academic work. 

Yes, I agree. On this cold May Sunday I'm currently very busy being touched to the bone by the excellently recorded live show of Damien Rice in Amsterdam I visited in 2014. There's always more to listen after that so for me there's little time for discussions that don't further help me to enjoy either music or this hobby. Enjoy your work.

[Antoine]

But..... If the TCP protocol is used it is assured that all network packages are received correctly. Put them in a buffer in the receiving device and once full enough stream and play them. So with that reasoning I though bit perfect is bit perfect....

You don't want to use TCP for streaming (due to latency), but RTP/UDP. Retransmission is typically handled in the RTP stack. Different retransmission strategies can be put in place. For example, for video, you don't need to retransmit past frames since they would arrive past their display time. For audio, you don't want to miss any packet or else you will hear glitches.

Latency is a non issue for non-broadcast music replay (in the home setting, not studio's) and asynchronous protocols that typically perform buffering. The only exception I can think of is when a single source is streaming to multiple and/or different receivers/endpoints.