Point of higher priced streamer?

@cleeds SG = SQ 😂👍🏻And I don’t know how it’s affected.

Let me see if I understood this correctly.

On one end we have streaming services, Spotify,Todal, Qobuz and for simplification I’m counting Roon for this catefory as well. These service will take the individual tracks from their data location and apply some algorith that converts the original file for the appropriate quality needed for the streamer. Next thing is the streaming service itself, which basically cuts the track to datagrams, let’s say 5ms slices and wraps these to tcp protocol (seems to be protocol for atleast Spotify and Roon, don’t know if Tidal and Qobuz are using udp).

Now at this point there would be a steady flow of individual datagrams to the streamer. If any of the tcp packages would drop, the tcp stack in streamer software would just ask the ”server” Spotify, Roon to resend the package. As long as the datagrams are coming in fast enough network package loss shouldn’t affect the SG, but in a situation where the network delay is longer that the cache time of the streamer it’s forced to drop the datagram. Based on the error correction schema this might not be a problem, if for example 40ms of audio is distributed in 8 datagrams. Each datagram would overlap 5ms with the previous one, so loosing one would not affect the integrity of data. More robbust error correction means more bandwidth is needed, if I understood correctly typically these schemas would be applied dynamically.

Now the streamer has received enough datagrams to fulfull the cache to ”protect” the flow to the dac. On the streamer’s RJ45/Wifi receiver chip there is incoming flow of datagrams and at the same time as the same packets are pushed out through USB/spdif port using AES3 protocol. This most like the point where jitter and electrical noise would be interfiering the output signal of spdif for example. How the missing data in spdif flow would affect SG is not clear to me, maybe someone else could open this in more detail.

Now if I have roughly understood the whole flow correctly it’s quite easy to understand why one streamer - dac combination sounds better that other. 

@audio2design, my point was just that it’s unclear to me how data loss would affect SG. As if streamer misses one datagram containing 5ms of data, it could be a silent point in a track resulting only note playing longer, but it also could be something else which affects the SG more profaundly. This also comes down to how streamer and dac handle these errors. As there is no error correction (as far as I know) between streamer and dac over any connection, it’s impossible to request packet resend from dac point of view. Assuming that these devices are separate boxes. So any error generated before dac could surface in a different way in SG.