UPnP Audio Streaming: Error correction by retransmission or by interpolation?

[Diego]

Hello everybody!

 

As far as I understood the technical articles I have read about the topic up to now: USB audio protocols do not use exact error correction. E. g. if some information from the computer does not arrive at the USB DAC, the DAC fills the gap, estimating the value with an interpolation (estimated value). In this way, USB audio is different from USB data transfer, where errors are correcting be retransmission of the same data.

 

Opposite to that, I did not find any information about the question, whether UPnP audio streaming data is error corrected by estimation (interpolation) or by retransmission. Does anybody know about this, and does anybody have a link to some reliable article to this question?

 

Thanks!

 

P. S. Please do not discuss in this thread the question, whether these differences between data and audio streams with regards to the error correction has an influence (or not) on the sound quality. If you are interested in this question, please refer to the numerous threads and posts where this is discussed.

[jhwalker]

Hello everybody!

 

As far as I understood the technical articles I have read about the topic up to now: USB audio protocols do not use exact error correction. E. g. if some information from the computer does not arrive at the USB DAC, the DAC fills the gap, estimating the value with an interpolation (estimated value). In this way, USB audio is different from USB data transfer, where errors are correcting be retransmission of the same data.

 

Opposite to that, I did not find any information about the question, whether UPnP audio streaming data is error corrected by estimation (interpolation) or by retransmission. Does anybody know about this, and does anybody have a link to some reliable article to this question?

 

Thanks!

 

P. S. Please do not discuss in this thread the question, whether these differences between data and audio streams with regards to the error correction has an influence (or not) on the sound quality. If you are interested in this question, please refer to the numerous threads and posts where this is discussed.

 

AFAIK, DACs do not interpolate missing bits - they simply emit a "tick" sound or a burst of static or whatever. CD players have the capability of attempting to reconstruct data streams "on the fly", but I don't believe DACs do this at all. Also, real-time streaming over USB is different from bulk transfer mode: real-time streaming has no error correction, bulk transfer mode does. Theoretically, bulk transfer mode DACs would have an advantage in ensuring bit perfect playback over the ones using streaming, but not too many DACs are built that way - don't know why.

 

OTOH, UPnP is based on Ethernet networking, and there is a protocol for handling errors built into Ethernet (i.e., retransmission requests for dropped / missing packets). Not sure how this works for real-time streaming.

 

Should be an interesting discussion - I love understanding how computer technology is being repurposed for audio storage and playback

[Diego]

Also, real-time streaming over USB is different from bulk transfer mode: real-time streaming has no error correction, bulk transfer mode does. Theoretically, bulk transfer mode DACs would have an advantage in ensuring bit perfect playback over the ones using streaming, but not too many DACs are built that way - don't know why.

 

OTOH, UPnP is based on Ethernet networking, and there is a protocol for handling errors built into Ethernet (i.e., retransmission requests for dropped / missing packets). Not sure how this works for real-time streaming.

 

Should be an interesting discussion - I love understanding how computer technology is being repurposed for audio storage and playback

 

My guess is, that the real-time (audio) streaming protocol has been defined in times, when the USB speed was limited in a way, that made it impossible to consider retransmissions without interrupting the audio stream. Today with USB 2.0 or even 3.0, the interface speed would not be the bottleneck anymore, so exact error detection and error correction could probably theoretically be used such as with data transfer (this is easy to guess for my as a non-technician: To transfer a sound file over the data transfer mode in USB 2.0 from one computer to another takes consistently less time than the playing time of the file, for all usable resolutions). However, to introduce a new protocol for this will probably not be considered, as the demand would be pretty low (except maybe for proprietary and therefore expensive hardware/software).

 

Given that UPnP streaming was developed in a later stage than USB streaming (afaik), it might be possible that error correction is used just as if it was a normal LAN-file-transfer. On the other hand, the UPnP-protocol was developed with hi-resolution video in mind having to travel over a fast Ethernet or maybe maximum of n-type WiFi (as higher standards were not known yet). This makes it possible however, that the exact error correction was again traded in against transfer speed, such as with usb audio streaming.

 

It would not surprise me, if error correction was discarded, given the fact, that most of these IT protocols are not developed with users in mind who care about the latest bit of quality, but rather the masses of users, who want streaming to work robustly, easy, "PnP", with cheap hardware, and who do not care so much about the difference between 98% and 100% of the possible reproduction quality.

 

However, it would be nice, if somebody who knows about this for sure, could answer the question...

[Cebolla]

If error correction is discarded, it's more likely to be at the streamer playback process, rather than within the UPnP protocol itself. I'd have thought it'll be far easier to use hardware that deals with conventional handling of network errors built into the UPnP protocol stack and for the playback process to just cancel and move on if it can't wait for the errors to be handled in time, resulting in drop outs as opposed to using 'doctored' UPnP hardware with built-in ignoring of network error correction, ie use of a non-standard network protocol stack.

 

A 'quick' look into the weighty UPnP specification documentation looks like conventional network protocols such as SOAP, HTTP and TCP are used, so it's unlikely that any non-standard hardware would be approved for use as supporting UPnP.

[Diego]

Would be basically great news, if UPnP would use "exact" error correction, using check-sums and re-transfers. Given that today's ethernet connections are fast enough to have a lot of bandwith left for re-transfers, at least when streaming 2-channel audio, even if it is uncompressed and high resolution.

 

I hope that UPnP receiver modules as built into hifi devices really take advantage of this.

 

This might hopefully result in more robust connections and avoid potential quality degradation due to transfer errors. Anyway, this would again raise the question, why certain testers consistently pretend to hear differences among different ethernet cables, apparently even in double blind tests, given that a word document gets over ethernet connections without any error, even through the cheapest wires. But as I wrote in my first post, I don't wont to enter into this discussion here, as there are plenty of other threads for discussing this.

[davide256]

Wrong ball park for the governing principle. Data transmission protocols originated in the days of noisy analog lines so error detection is trivial. Where the difference is made is in how a remote receiver is able to buffer data and correctly recover sequence/timing. UPNP/DLNA has to assume terrible jitter because its a network transmission and networks suffer variable latency based on traffic load. its elasticity should be much better than asynch USB which assumes a dedicated point to point data transmission.