Internal streamer (Devialet Expert) at the end of 2016

[Xander]

Why do we need an internal streamer if AIR / MacBook/ iTunes is working?

[Antoine]

Perhaps to support more different streaming protocols (like uPnP for NAS playback or Roon's RAAT) or to embed protocols or endpoint software in the Expert series negating the need for an external computer (like Spotify Connect).

[arcam]

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.

It depends how much buffering the user is willing to accept. When I first installer AIR (2), the default buffer size was set to about 15 seconds (OSX > Wi-Fi > Ether > 200), which was highly inconvenient when skipping tracks frequently or wanting to fast pace or backtrack. This kind of control you cannot achieve with TCP, even in the home environment (who knows what other traffic is also competing; there is a lot in my setup).

[octaviars]

Why do we need an internal streamer if AIR / MacBook/ iTunes is working?

To get rid of the computer, I use Bubble UPnP app on Android and if Devialet supports UPnP with the new board I just need my phone and my Devialets to stream from my NAS and Tidal no computer. But I would like to see support for ROON that would be the best thing and many of us want that. Run ROON on a NAS or a small computer like the sonicTransport would be a really nice thing to have.

[Antoine]

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.

It depends how much buffering the user is willing to accept. When I first installer AIR (2), the default buffer size was set to about 15 seconds (OSX > Wi-Fi > Ether > 200), which was highly inconvenient when skipping tracks frequently or wanting to fast pace or backtrack. This kind of control you cannot achieve with TCP, even in the home environment (who knows what other traffic is also competing; there is a lot in my setup).

I agree that those high levels of buffering (AIR had a maximum of 5s if I remember correctly) are there only for poor slow/unreliable networks. Seconds of buffering for a typically low bandwidth audio shouldn't normally be necessary or desirable. In the case of AIR it's there to mask other issues and even there it seems to fail in some cases due to the issues most likely not being related to buffer underruns but rather poor buffer management/corruption or timing/sync issues.

Even low latency 'local' protocols like ASIO perform some buffering.

UDP is a 'lower cost' data exchange network protocol, lower cost in the way that there's less overhead for sender, receiver and intermediate transport network. In a home situation for streaming offline music data I think there's generally no real need/advantage but it could be a nice to have. It's not really relevant to the buffering strategies for music or even video playback.

[iamwappie]

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.

Why not use TCP? I'd think real time is not desired as we get into the issues we currently have. If I disconnect my Roon instance by pulling out the network cord the devialet also stops playing immediately. So no buffer at all which also means that if there is the slightest non performance of network or the chain involved you have an issue.... I Suppose AIR is suffering from such a problem.

Already said it in another thread here; When I pull the network cable from my Logitech Media Server the squeezebox keeps playing for maybe 20 seconds just from its local buffer, filled by using a trustworthy transmission protocol

[Antoine]

Well there's always some buffering going on somewhere, be it in a driver, interface like ethernet/usb, player and/or hardware. RAAT for example does it too (https://community.roonlabs.com/t/jplay-a...-2/9525/13). It could be the buffers are just to small (e.g. 50-200ms) for us to notice music not stopping at the exact moment you disconnect a cable.

[Confused]

Some people already paid up to £1000 for the AIR card as an extra which until very recently (and still not necessarily fixed for all) hasn't worked 100%.

Did anyone ever get charged for the card? I thought it was on permanent 'free offer' or something.

I'm guessing this is a general upgrade is on board processing power to allow them to do all sorts of stuff the current hardware would be stretched doing currently.

You could argue that we have all paid for the card.  The 'free' AIR card could be considered a £1000 discount, it cost money to make the card, Devialet have made a profit, so it was never really 'free'.  Furthermore, the AIR card was not optional for buyers of the D240 / D250, so buyers of these cirtainly didn't get anything for free.

[Rufus McDufus]

Why not use TCP? I'd think real time is not desired as we get into the issues we currently have. If I disconnect my Roon instance by pulling out the network cord the devialet also stops playing immediately. So no buffer at all which also means that if there is the slightest non performance of network or the chain involved you have an issue.... I Suppose AIR is suffering from such a problem.

TCP could be used, but the advantage with UDP is the sender can just fire out the packets and not care what state the receiver is in - it's stateless. In the case of TCP if a packet is lost then the sender has to resend which means maintaining a buffer of lost segments for every client. There's a lot more overhead to this operation, plus more overhead to actually setting up the connection in the first place . Also in the case of multiple clients the overhead if using TCP increases in proportion to the amount of clients. UDP can be received by multiple devices on the network (devices in several rooms perhaps) with no additional overhead on the sender.

There's a bit more to AIR than just UDP, I seem to recall it has some error checking (and time stamping of some description?) built-in so it does display TCP-like behaviour but using UDP as a basis.

[iamwappie]

You are absolutely right in the overhead of TCP but the bandwidth required for audio isn't that high an hence the overhead should not be that of a concern I'd think but maybe I'm wrong.