In the continuing saga of ironing out the bumps in the deployment of the Mini and the EyeHome in the living-room A/V stack, even after the downgrade, the EyeHome has an irritation habit of dropping the audio, stuttering in the annoying manner familiar to internet audio stream listeners. The troubling aspect of this is that the datachannel should be much larger than the amount of data running to the box.

The current setup has the data running through the Mini from an external HD via USB 2 and thence to the EyeHome via 100-base Ethernet. The EyeHome then runs video out via S and audio via optical. Still, it takes a noticeably long – and aggravating – period of time before a song loads and begins to play, and inevitably, it stutters. This is less impressive performance than the wireless streaming device I inherited from Manuel, and much less impressive than the little iTunes/printer-server/ airport widget I was initially using to stream. Currently that’s a dedicated printserver but if it can do optical out it might be a better device for audio.

Playing the audio directly from the Mini via iTunes is also, surprisingly, producing some audio stutter, and looking at RAM usage may provide a clue – I did not upgrade the box from the vanilla 256MB config and EyeHome is reported as requesting a staggering 1.5GB of virtual memory, along with an ever-increasing number of threads (25 last time I checked), making me strongly suspect the application of some not-very-neat memory usage techniques.

An additional annoyance when playing audio directly via iTunes is the hushed line-level output of the headphone mini-jack. I am nearly sure that there are iTunes plugins to address this issue.

Oddly, video playback via the device is seamless and stutter-free, despite the memory usage issue. I wonder if it’s a function of the size of the asset bases – less than 100 media files in the video-playback archive versus about five thousand in iTunes.