UPnP Sound Quality

[thumb5]

@ada Just because AIR is based on UDP does not mean it has no hand-shaking or guarantee of delivery, etc. as you stated above.  It is quite possible to add these capabilities over UDP.  In fact (as I'm sure you know) both TCP and UDP are layered over IP, which has the same inherent lack of reliability as UDP.  TCP implements guaranteed delivery by using synchronisation/acknowledgement and retries, but its design is not optimised for real-time data transfer.  AIR can equally implement (effectively) guaranteed delivery over UDP by using retries in a different and proprietary way.

My investigation into the AIR protocol suggests that it does have feedback mechanisms that would allow it to deliver a bit-perfect stream to the renderer.  These are somewhat similar to TCP but simpler, if I understood them correctly.  Its job is probably made much easier because the large buffer in the Devialet amp means that it does not have terribly hard real-time constraints.

If the AIR protocol used "raw" UDP with no overlying mechanism to give any reliable, ordered delivery, then depending on the quality of your network and the other traffic on it, I think you'd hear much worse artefacts than the kind of differences (narrower sound stage, lack of harmonics, ...) you discussed in your original post.  Specifically, significant drop-outs, stuttering, and/or obvious distortion.

In short, I'm pretty sure you're barking up the wrong tree here: the difference between AIR and UPnP is not down to one being bit perfect and the other not, and not due to the difference between TCP and UDP.

[ada]

@thumb5 you have a point, they may have the all the correction and the integrity checks in the application level but that will make everything even much more complex then respecting a built in low level mechanism that comes in TCP. There is a basic strategy in all over software development world, separate the infrastructural and application level solutions as much as possible to decrease the complexity. If we assume that Devialet went beyond the TCP synchronisation/acknowledgement, then they should have hell amount of validation, dropping, re-requestion, re-queueing operations. For such a low power device like Devialet board (think that the Air was also active before the powerful CI) this will be too much in the application layer to handle and it will be too complex to handle.

Of course, all my comments are estimations, I really don't know why should we chase realtime over quality, in my opinion if we are talking about a local network and a latency of less than a second (Airplay has 2 seconds initial delay for example) I really prefer to go for the most robust and reliable way then having a real time solution. We don't chase any life critical operation here, we are not in a recording session to care the real time operations neither, what we care is the quality and the integrity of the content.

And for the AIR protocol, yes, it would have a way in application layer to provide a bit-perfect solution, but again really, won't be it too complex to do in application layer while you can assign some of this integrity tasks to the default TCP package operations that comes by default in a lower level. And I am sure I am not the only one sees issues in the AIR protocol that doesn't matter if you have a direct connection between your streamer and the unit or you have a switch between them. I think the correction or whatever feedback they have is already failing in some aspects.

And for the audio quality, I think we have enough examples of ghost voice, pink noise, glitches, shutters, cracks via AIR protocol. Almost all the people face one or some of these problems randomly. And lack of definition can be clearly a reason of a uncorrected data stream. If we think about the concept of jitter vs bit resolution and as much as you have faulty bits you will lose the real sound that supposed to be presented, this will start to cause lower resolution. Think live adaptive streaming technologies we use in the modern video and audio streaming. You don't have interruptions or unexpected buffering in these services, you only see low resolution images or low resolution sound. Compare low resolution audio to higher ones or lossless ones, the main difference will be sound stage and the resolution. I am not saying I found the root cause but my point is not completely unrelated. And maybe Devialet puts extra empty bits when they start to lose packages that will also narrow down the resolution. (Of course this last sentence can be a bullshit as this will go under codec level operations)

I have never pointed directly to bit perfect as the root cause, I don't believe the UPnP is bit perfect solution also. There can be still problems in TCP protocol. And my findings and arguments are mainly running with full of assumptions. I am not saying they are all truth but at least now, I have a reason why USB and UPnP are sounding much better than a Devialet's closed source solution. At the end, it is impossible to compare without knowing how the AIR protocol works in real. Maybe all they do is a simple feedback message or they have a super complex and advance algorithm to fix all the mistaken packages. (At least last part is impossible to believe for me as I suffer a lot with AIR protocol)

[thumb5]

The errors will not be in the form of corrupted packets, because each packet has a frame check sequence; if the data in a packet are corrupted, the hardware simply drops the packet. So the typical failure modes of UDP are based on missing packets and/or (possibly) packets delivered out of order, not single-bit errors or even single-sample errors. Given a big enough buffer on the receiving end, it's not hard to imagine how sequence numbers, time-outs and re-transmission could be used to build a reliable packet stream out of UDP. And once you have a reliable packet stream, there are no other errors to consider. In other words, it does not have to be "super complex" to be as good as TCP - for this application, with this hardware.

Of course, I'm not arguing that you don't hear a difference. But I don't think you've picked on the explanation for what you hear.

[ada]

Yes you are right on having FCS but even if you don't have corropted packages, there is no way to gurantee the order of the packages that unit receives are correct. While having this as an issue if you also start to have drops because of the corruption, then ordering the sequence numbers will be quite complex. Because as the FCS is correct, in the low level you won't fail but when you reach to the application layer, you will have to check the sequence and request the dropped ones and reorder them again. I am not saying it is impossible to have but why do you want a solution like this in your application? And what happens if somehow you lost the buffer or what is the chunks size you feed the player in the unit? What is implemented to check the integrity of the chunks. I am not fighting or trying to prove anything here but having UDP for bitperfect streaming and high quality playback sounds super hard for me. (Maybe I am not enough talented to design the solution, that's aslo fine)

Just an example, please check this article, see how many time they mention for UDP: One would use it when speed of the transport is desired, not quality or reliability. I am not a network expert, I only have CCNA level certificates from university years that I already started to fail in some parts.

[thumb5]

I think we're actually agreeing about this, so I won't labour the point too much. Just to say that there is no particular magic in TCP: it does the kind of thing you describe above and then ask "why do you want a solution like this in your system?" The answer is that if you want to stream audio over IP then you have to have a solution like that, for exactly the reasons you said - but it doesn't necessarily mean it has to be TCP. In fact, the "problem" AIR is trying to solve is actually simpler (more constrained) in some respects than what TCP has to do, so the AIR protocol could be less complicated than TCP.

That said, I know AIR does not work perfectly for everyone so it certainly has its faults.

[Confused]

@ada @thumb5 - It is clear to me that you knowledge regarding network protocols is at a level (or two) above mine, I know some of the basics but this is not my area of expertise.

Over on the other UPnP thread, a number of users, including myself, have reported issues with stuttering and drop-outs using the CI board and UPnP. There is also some discussion about how individual networks are set-up. The implication being that there is some subtlety in the network that is causing the issue for some.

Here is a simple question. If I run JRiver UPnP to the CI board I get stuttering and drop outs. Using the same PC, and the same network, I can stream JRiver UPnP to my microRendu, and it is perfectly stable and sounds great, no issues. The only difference in the set-ups is the CI board versus the microRendu. So why is this?

With my feeble network knowledge, it looks to me like it is not the network or the protocols that is the issue, but something in the CI boards implementation of UPnP.

What do you think?

[ada]

@Confused there can be a lot of reasons behind this. Firstly we don't know what kind of playback library Devialet use on their system and we also don't know if they use the same playback flow over USB and over Ethernet (for USB they may have I2S) and for an Ethernet-based solution they may have custom flows. This means it can be an issue on Devialet side but also it may not be because as UPnP is a flexible and try to be "universal" it comes with a variety of ways to implement a solution.

In their documentation, these are the example scenarios: 

EXAMPLE PLAYBACK SCENARIOS ...................................................................................... 17

1. 4.1.  3-BOX MODEL: ISOCHRONOUS-PUSH (IEC61883/IEEE1394) ..................................................... 17
   
2. 4.2.  3-BOX MODEL: ASYNCHRONOUS-PULL (E.G. HTTP GET) .......................................................... 19
   
3. 4.3.  2-BOX MODEL: CONTROL POINT WITH DECODER USING ISOCHRONOUS-PUSH (E.G. IEEE-1394) ... 21
   
4. 4.4.  2-BOX MODEL: CONTROL POINT WITH DECODER USING ASYNCHRONOUS-PULL (E.G. HTTP GET) 23
   

4.4.1. Minimal Implementation.................................................................................................. 23

1. 4.5.  2-BOX MODEL: CONTROL POINT WITH CONTENT USING ISOCHRONOUS-PUSH (E.G. IEEE-1394) ... 24
   
2. 4.6.  2-BOX MODEL: CONTROL POINT WITH CONTENT USING ASYNCHRONOUS-PULL (E.G. HTTP GET)26
   
3. 4.7.  NO CONNECTIONMANAGER: REPAREFORCONNECTION() ACTION ............................................... 27
   

ADVANCED PLAYBACK SCENARIOS.................................................................................... 29

1. 5.1.  SYNCHRONIZED PLAYBACK....................................................................................................... 29
   
2. 5.2.  MULTI-STREAMING .................................................................................................................. 31
   

This means we will never be sure about where is the problem. But I see some 401 errors between Audirvana and Devialet already, I am not very optimistic about UPnP in the future as the scenarios are a lot different and having a robust and solid alignment between the streamer and renderer from different brands won't be so easy.

Ref: http://www.upnp.org/specs/av/UPnP-av-AVA...101231.pdf

[K4680]

Hi Ada, in January my devi came back from the upgrade! Since that time I only play over Upnp, -> Router-> Melco-> Ethernet-> Devialet. as an app I use AK Connect, SQ better than USB! Very satisfied

[Inox]

HI All,

I tried Audirvana UPNP vs Audirvana Air Wifi with my Devialet. The difference is mainly "hardware". With UPNP, the file is played by the CI Board. With Air it's played in the computer and the flow is sent to the DAC directly.
My preference goes definitely to Audirvana Air in terms of transparency and bass definition. I find Audirvana UPNP less precise and a bit "boomy".
With an external wifi antenna connected to the Devialet and placed in the vicinity of my Wifi hotspot, and the latests Devialet firmwares, I never have a single glitch or cut any longer.

A question : is it possible to use room correction (AU Plugin, like DIRAC) with Audirvana UPNP like Audirvana Air ?

[ada]

@Inox I think I started to understand the possible differences here. As with the release of AIR 3.x, Devialet has removed the bit-perfect or any other kind of advanced configuration from the AIR settings. Probably to enable most smoothes possible streaming, they implemented a solution based on available bandwidth between the player and the unit. That can be the root cause of the issue. I will start to do more tests based on this idea but when I tested for the first time, even with a direct cable connection between iMAC and Dev was still faulty in the AIR protocol.

BTW, for anyone that would like to test the UPnP configuration, there are some development tools available: http://www.meshcommander.com/upnptools

You can download it in Windows (or you can run windows in a virtual machine like what I am doing now) and there is a tool called "AV Media Controller", that tool basically gives you information about the current playing song. What I see with my Audirvana setup, the bitrate, and quality-related data is not presented but the file format is wav. If you use JRiver, you can at least check which kind of format is in use.

There are other tools also to create a UPnP server and more. Here is the information that I got with my Audirvana over UPnP:
   

I am also running another tool right now, it is called Device Validator, basically, it runs tests on the device to be sure the UPnP integration is done in a proper way, it takes a bit time but until now the Devialet integration passed all the tests with some warnings.