AIR1 v AIR2 v Spark

[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