AIR user survey

[rik]

One thing that may be contributing to the white noise issue is that Dev' are (I think - no documentation) using Multicast UDP for AIR.

Linn has some issues when they used multicast UDP for their multiroom protocol which were found to be caused by switches and hubs not handling multicast UDP/IP correctly. If I remember the Apple Airport Extreme and BT Home Hub 2 were particularly poor in this respect.

Does anyone with a managed switch have this issue?

Rik

---

Using iMac > Wifi > Apple TV > optical > Devialet 200
No problems using Apple TV

Hi canyelles,

Don't forget that the Apple TV does resampling for 16/44.1 audio to 16/48.

PS: The Airport Express doesn't [Converted to 16/44.1 ALAC at the source] (& you can disable the Wi-Fi).

Just a FYI - Rik

[thumb5]

One thing that may be contributing to the white noise issue is that Dev' are (I think - no documentation) using Multicast UDP for AIR.

Rik - I know AIR uses unicast UDP for the streaming protocol, but thought it used broadcast (rather than multicast) for the discovery and control aspects.

I agree, it would be extremely helpful if Devialet would publish some specification of the protocols they use.

Ian

[canyelles]

One thing that may be contributing to the white noise issue is that Dev' are (I think - no documentation) using Multicast UDP for AIR.

Linn has some issues when they used multicast UDP for their multiroom protocol which were found to be caused by switches and hubs not handling multicast UDP/IP correctly. If I remember the Apple Airport Extreme and BT Home Hub 2 were particularly poor in this respect.

Does anyone with a managed switch have this issue?

Rik

---

Using iMac > Wifi > Apple TV > optical > Devialet 200
No problems using Apple TV

Hi canyelles,

Don't forget that the Apple TV does resampling for 16/44.1 audio to 16/48.

PS: The Airport Express doesn't [Converted to 16/44.1 ALAC at the source] (& you can disable the Wi-Fi).

Just a FYI - Rik

Thanks, I know about the resampling, I mentioned it when I posted in the white noise thread.

I can't hear any issues though, I am happy using Apple TV until they fix the AIR bugs.

Maybe Apple will bring out a new Apple TV that leaves the sample rate alone.

[rik]

You can use (any) of the Airport Express devices as a digital source. they don't resample and can be Airplay'ed from any iOS device (or Mac running Maveriks or better). The older (plug like) Airport Expresses and be had for a very reasonable amount and you can disable the WiFi in them.

Rik

[Rufus McDufus]

I use a managed 24-port switch rik - not sure if it makes any difference managed/unmanaged. I don't get white noise issues from AIR from either of two PCs. However I do get dropouts with no noise from the far-more powerful PC occasionally. I've often wondered if it's related to ACPI/possible sleep-related issues but all is turned off auto-sleepwise for maximum performance and I don't get any errors in the event logs to tie in with the dropouts.

[rik]

In general managed switches tend to be better - mainly because they are 'more' standard compliant. [Obviously there are lots of other reasons why a managed switch is preferable but I'm just thinking UDP & AIR here].

One of the problems I believe Linn was that they had a professionally installed / managed wired network (Cisco I think) so they didn't see the issues which consumers had. Linn have a very good web site which had recommended network configurations - the DS range is UPnP based but a lot of the lessons learnt will be applicable.

Rik

[Borgen]

That might make sense. I am also running with a Cisco managed switch (wired connection) and so far I have not noticed any white noise (have only been running it in this configuration about 2 weeks though).

[Jean-Marie]

Hi there,

I'm getting very occasional dropouts (sometimes 2 in a day, sometimes no drop out for days and weeks).

However, I have noticed something interesting: Every time I'm getting such a drop out, the following type of log is showing on the Mac OS console:

Sep 5 07:16:47 mbpr kernel[0]: IOAudioStream[0xffffff801a93e000]::clipIfNecessary() - Error: attempting to clip to a position more than one buffer ahead of last clip position (468,7e0)->(469,9e0).
Sep 5 07:16:47 mbpr kernel[0]: IOAudioStream[0xffffff801a93e000]::clipIfNecessary() - adjusting clipped position to (469,7e0)

Note that you need to have administration rights to have access to the log and the log is in /var/log/system.log.

I'm running OS X 10.9.5 and would be interested to know if others on Mac OS (I have found mention of such audio related problem on Mac OS since 10.4.x and with carious kind of interfaces (firewire, USB) with other products than Air) get the same kind of logs when they experience dropouts.

Best regards,
Jean-Marie

[rik]

Found this.

Those messages mean is that a client wrote to the driver at a spot that the family wasn't expecting. In this case, the client is wrote a little further in the future than the family expected. Usually, this just means that the client skipped some samples, probably due to an overload or some other thing that caused IO to skip some samples.
The log message about this is probably unnecessary and should probably be relegated to debug builds. Feel free to file a bug about it.


--

Jeff Moore
Core Audio
Apple

Rik

[Jean-Marie]

Found this.

Those messages mean is that a client wrote to the driver at a spot that the family wasn't expecting. In this case, the client is wrote a little further in the future than the family expected. Usually, this just means that the client skipped some samples, probably due to an overload or some other thing that caused IO to skip some samples.
The log message about this is probably unnecessary and should probably be relegated to debug builds. Feel free to file a bug about it.


--

Jeff Moore
Core Audio
Apple

Rik

Well overload on a 4 core Macbook Pro Retina which is running under 1 or 2% CPU load is a bit worrysome... These are also the only occurrence when I'm getting dropouts.

/Jean-Marie