13-Aug-2018, 22:52
@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)
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)
