AIR1 v AIR2 v Spark

[ThierryNK]

Save your time, if anyone can resolve the issue(s) it's Devialet and Devialet only. I'm not the pessimist here, just being realistic.

Well, trying not to be pretentious or vainglorious, I already helped Ayon, Lumin and Totaldac to solve network audio issues.

I do not pretend to be able to "solve" the issue inside Devialet gear, but maybe to get around it…

Let us try. It is only my time, and it costs you nothing. If I succeed, I like chocolates    If I fail, not a big deal.


After having Ian's input, here is what I suggest to try (if it has already been done, please tell me):

- Hardwire Devialet to an Ethernet switch, not the one of your Internet Box. This switch has to be hardwired to the internet box
- Hardwire the audio computer to this switch, switch off its Wifi, if it has one. Kill all internet software, browsers, mail, etc.
- Wait a minute, and unplug the cable that goes from the switch to your Internet box. You lose internet access, but the Devialet and the computer should continue to see each other.

Use the tracks that lead to the white noise and keep me posted.

Best regards

[Magagne]

I tried the ultimate and the most simple connection path. I strip down all possible noise variable that can affect streaming. It is by using RJ45 directly to the devialet, no router/switch, no network in the equation. Just a hardwire, static address, direct connection.

1- Took the IP address from Devialet (use static IP address mode instead of DHCP mode, 192.168.0.77).
2- Configure my MacMini with a static IP address IPv4, base on the same subnet of the Devialet IP (192.168.0.XY).
3- Plug my MacMini directly to the Devialet with RJ45 CAT6 cable, 4 feets long.
4- Last version of OSX version, last update, last Firmware.

I resume again, so NO router, NO switch, NO wifi (MacMini wifi was OFF too), NO network. Full hardwire, direct connection, MacMini + CAT6 + Devialet 120 that’s it. I cannot do more simple than that.

Start itunes, with DevialetAir, in ethernet mode. Well, after some time, with hires, same cracking/white noise crap, even if I adjust the buffer size.

Hypothesis: Is that can be possible that there is a bad batch of the network card from Devialet? That will explain why some user has problems, and some don’t?

[IanG-UK]

I did a similar test to you some time ago, Magagne, with similar results. I am, however, going to repeat it in the next day or two just as a retry.

Maybe the network cards are variable, but Devialet took both my 250s to their factory to check them and they said each was ok.

My hypothesis is that the clock quality in the Mac is variable. Some people get no white noise at all, using Macs; some, like me, get it frequently but irregularly.

[ThierryNK]

Hi

As Magagne has already tested the configuration that I asked Ian to check, did someone test the "optical bridge"?

Ethernet Interfaces should all have galvanic isolation, for safety reasons. It is a norm. But it has been shown that high frequencies EMI pass through this galvanic isolation. Maybe Davialet Ethernet does not have this galvanic isolation or a very weak one.

I already evaluated several solutions for galvanic isolation as Giso:
http://www.audiophile-magazine.com/bancs...seau-giso/
And also filtering ethernet cable from Totaldac:
http://www.totaldac.com/ethernet_cable-eng.htm

But the most efficient is an optical bridge.
Optical bridge has already solved the noise issue on Devialet as seen on the link I posted in an earlier post.

The investment is not too expensive, about 100€  including a battery. 

You need 2 media converters of this kind:
http://www.ldlc.com/fiche/PB00103085.html

And one monomode SC/SC optical fiber as:
http://www.ldlc.com/fiche/PB00089183.html

Setup is quite straightforward.

Switch or computer
Ethernet cable
Media converter
Optical fiber
Media converter
Ethernet cable
Devialet

I also use a 5V battery on the media converter that is connected to the audio gear, to avoid the EMI of the switching power supply of this media converter that will go through ethernet. As this one:
https://www.amazon.fr/gp/product/B00N9W5...UTF8&psc=1
With this cable:
https://www.amazon.fr/gp/product/B00DELC...UTF8&psc=1

Initially, this kind of stuff is to filter EMI coming through ethernet to improve the noise level inside a streamer.

Apparently, there is something bad coming through ethernet that makes Devialet behave badly.
This cannot be "computer clock" because ethernet transmission happens in the range of 10 MHz which not the frequency of the audio signal (same for USB) .

Filtering ethernet is mandatory in health gears as scanners or MRI to avoid electrically killing people. 

Also use cat5e well shielded ethernet cables. Going to cat6 or cat7 is a mistake. You do not need them for audio, and you raise the bandwidth, raising the amount of EMI that can go through the cable.
Shielding and metal connectors  (no plastic) are the 2 main characteristics for ethernet audio. Some € on ebay. 

For Antoine, you do not always need to know exactly what is happening "inside" to try to solve a problem. As I say sometimes, you do not need to be God to cure people.


Nevertheless, I have a fear.

If it is the internal Switching Power Supply of Devialet that is the source of EMI that shut down the ethernet, and Switching Power Supplies are a HUGE source of EMI (check with Google), then I have no solution to propose. Better shielding should be required inside Devialet. And that is one of the reasons why High End audio gears have often an external power supply. 

If optical bridge does not solve the issue, well, I won't get chocolates. 

Kind regards.

[PhilP]

As far as I can remember, on Macs the white noise problem first appeared when Mavericks and AIR 2.1.3 (and I think FW 7.1??) first began to be used in combination.  I believe that AIR was stable on previous versions of OS X and therefore think its unlikely that white noise is a networking problem - its more likely to be a problem with how AIR works in combination with the later versions of OS X (and various versions of Windows). [EDIT: and some users have reported that they have no problems with Mavericks and AIR...]

Jean-Marie posted here back in June that Devialet use Qt for AIR and that there is therefore likely to be significant common code in the OS X and Windows implementations which may well explain why white noise appears on both O/S.

I regularly use AIR wi-fi to stream 24/96 files with absolutely no issues and can stream 24/192 files again with no issues.   I use a cheap Netgear wi-fi modem/router and Cat 6 cable and it all works perfectly.  No doubt it could be improved but I don't think there is too much wrong with Devialet's networking approach 

[GuillaumeB]

I don't think there is too much wrong with Devialet's networking approach 

That seems like quite a strong statement given the number of people that have reported dropouts and stuttering on here. In fact one person (Womaz?) was able to reduce the incidence of white noise by simply changing the location of their computer strongly suggesting a network-related issue.

My feeling is that the problem is highly complex and multifactorial, otherwise it would have been solved by now. For instance I have heard reports of the frequency of white noise being reduced through the use of mains conditioners which didn't really make much sense at all.

On a number of occasions Devialet have claimed to have fixed the problem only to have the proverbial Jack-in-the-box pop out with mallet in hand.

Guillaume

[ThierryNK]

As far as I can remember, on Macs the white noise problem first appeared when Mavericks and AIR 2.1.3 (and I think FW 7.1??) first began to be used in combination.  I believe that AIR was stable on previous versions of OS X and think its unlikely that white noise is a networking problem - its more likely to be a problem with how AIR works in combination with the later versions of OS X (and various versions of Windows).

Jean-Marie posted here back in June that Devialet use Qt for AIR and that there is therefore likely to be significant common code in the OS X and Windows implementations which may well explain why white noise appears on both O/S.

I regularly use AIR wi-fi to stream 24/96 files with absolutely no issues and can stream 24/192 files again with no issues.   I use a cheap Netgear wi-fi modem/router and Cat 6 cable and it all works perfectly.  No doubt it could be improved but I don't think there is too much wrong with Devialet's networking approach 

Well, a port scan that crashes an ethernet interface IS something wrong. 

Tcp/ip protocol that goes through ethernet cables and all around the world on internet is a bullet proof network protocol, with data check, receipts, and requests to send again data if not received. 

When there are side audio effects on an ethernet transmission, there are very few reasons:
- EMI going through the cable
- sending "bad" data, so responsibility of AIR software on the computer side  (but no issue on USB for same kind of data)
- not recognizing errors and/or not asking them again on incorrect reception inside Devialet. 

If there was a big bug in AIR on computer side, it should affect 100% of users
Same for reception. 

There is a tiny possibility that some hardware/software configuration lead to a random effect of a bug. 

I does not mean that it is true, but with experiments that have been made, the current most probable reason for the issue is EMI, as:
- already solved by optical bridge
- every computer, software configuration, energy saving option, processor, memory, chipset, every ethernet switch, etc have a different EMI signature.

Again,  "most probable" does not mean 100% true. 

Regards

[PhilP]

I don't think there is too much wrong with Devialet's networking approach 

That seems like quite a strong statement given the number of people that have reported dropouts and stuttering on here. In fact one person (Womaz?) was able to reduce the incidence of white noise by simply changing the location of their computer strongly suggesting a network-related issue.

My feeling is that the problem is highly complex and multifactorial, otherwise it would have been solved by now. For instance I have heard reports of the frequency of white noise being reduced through the use of mains conditioners which didn't really make much sense at all.

On a number of occasions Devialet have claimed to have fixed the problem only to have the proverbial Jack-in-the-box pop out with mallet in hand.

Guillaume

I appreciate that it must be very frustrating for the people who do experience white noise or stuttering/drop-outs and as I've mentioned previously I've remained on 10.6.8 on my iMac for music in order to avoid any potential problems.  

White noise was first reported with AIR (2.1.2 rather than 2.1.3 as I said before and FW 7.1) on OS X when Mavericks was released and systems which had previously run fault-free suddenly developed problems. This is unlikely to be a coincidence...

I think it quite possible that white noise and stuttering/drop-outs are separate issues though as you say they may well both be multi-faceted problems.  It is apparent from posts on here that stuttering/drop-outs have in many (but not all) cases gone away when the network has been changed/improved.

I find it difficult to believe that my 200 or those Devialets owned by others who have no issues with AIR are somehow 'better' than those who do experience those issues.  I don't have a super-expensive, powerful network and have literally done nothing to optimise it. My wi-fi signal strength as measured by the Devialet is 43/+8 DBM and works with no problems...  Further I can use my iMac to perform other tasks at the same time as I listen to music as I am now ; 

Thierry, I guess you may well have a good point about EMI interference being a cause of some issues (stuttering, drop-outs) especially as you have shown that the Devialet may not have adequate protection against EMI but my gut feel is that white noise may have a different software-related cause. If you do find the cause of the problems then chocolates is the smallest prize that you should expect

[PhilP]

FYI, this was posted by Jean-Marie et al back in March

24-Mar-2015, 14:59

I have short drop outs only, quite infrequent: no more than once of twice a day for a 5 to 6 hours listening.

Everytime, I have been able to relate that to the known bug in MacOS related to "kernel[0]: IOAudioStream[0x4d83000]::clipIfNecessary() - Error: attempting to clip to a position more than one buffer ahead of last clip position (d24,39)->(d57,3b5)"

This is frustrating because the problem belongs to Apple but they ignored it for years (it is known to appear on some USB interfaces as well as firewire) and therefore, unless Apple corrects it which is unlikely, the only solution for Devialet is to work around it.

Is this a software bug or timing error?

It depends on how the clocks are handled but if they are not locked, and differ in frequency, they may eventually get more than one buffer out of step after a certain time. I would then expect this sort of error message.
The length of time between starting to stream music and the first hesitation would then depend on the difference between the actual computer and Devialet clocks involved, and if they were almost the same maybe one would not get a dropout in any realistic length of listening session. If they differ more maybe there will be a dropout in every session, and even more frequent with HR files.

To me this is a software bug that does not handle correctly timing variation and probably encounter some race condition.

I have done real-time development myself, and I can tell you that the vast majority of people, including realtime developers are not handling this kind of problem correctly and do not implement robust solutions.

So I am not that surprise that Apple is in that case.
MacBook Retina -> Air -> WiFi -> PLC -> Ethernet -> Devialet 120 -> AperturA Armonia

[ThierryNK]

Again, there is no specific "audio timing" in an ethernet transmission.

If there is a buffer on the receiver side, there is no "real time" involved, the same way you download a file from the internet.

If the buffer is not large enough compared to network latency and performance, than there are dropouts, but no "noise" in the audio output, except if an empty buffer crashes the audio process, and this is very unlikely.

Just unplug your ethernet cable, and listen how long the music still plays, it will give you an idea of the buffer size on Devialet.

Kind regards