Air & Devialet memory (technical)

[Hifi_swlon]

Apologies if this has been discussed already.

I'm curious about the technical details of Air, and particularly the memory in the Devialet.

I've not looked at my switch since connecting the d200 as it's in the cupboard. But I saw it today while streaming and noticed it's getting a continuous hammering. Not a problem, that's what they do, but I'm curious as to why. I'm assuming Air is continually sending very small packets of data, which seems like it would be more prone to error (and it's not like it's a very robust system).

On my network I can send a whole red book track off the ssd over the gigabit Ethernet in a second or less I'm guessing. So I would have expected the Devialet to buffer at least a track or two, and send the data in bigger chunks once it's got going, and full the Devialet's memory. This would surely be much more efficient. Unless it's memory buffer is really small?

Anyone know the technical details?

[PhilP]

Apologies if this has been discussed already.

I'm curious about the technical details of Air, and particularly the memory in the Devialet.

I've not looked at my switch since connecting the d200 as it's in the cupboard. But I saw it today while streaming and noticed it's getting a continuous hammering. Not a problem, that's what they do, but I'm curious as to why. I'm assuming Air is continually sending very small packets of data, which seems like it would be more prone to error (and it's not like it's a very robust system).

On my network I can send a whole red book track off the ssd over the gigabit Ethernet in a second or less I'm guessing. So I would have expected the Devialet to buffer at least a track or two, and send the data in bigger chunks once it's got going, and full the Devialet's memory. This would surely be much more efficient. Unless it's memory buffer is really small?

Anyone know the technical details?

Hi,  you might want to take a look at this thread which explains whats going on.  I still find the router activity irritating

http://devialetchat.com/showthread.php?t...d+activity

[thumb5]

I think the post that Phil linked to explains what's causing the frequent network activity when the Devialet is not actually streaming.  The network activity in that case is probably to do with the discovery mechanism used by AIR and/or the iPhone app.

For information about what's happening when it is streaming, you could take a look at this: http://devialetchat.com/showthread.php?tid=276.

As far as the buffer is concerned, I recall someone here (Antoine?) confirmed that the on-board buffer RAM is in the region of 1-2 MB, so nowhere near large enough to store a whole track but should be plenty to cope with timing variations and network delays.  By the way, I wouldn't describe that as "really small" for an embedded system.

That seems a reasonable design decision to me: it's hard to define how much memory you'd need to store a whole track -- how long is the longest possible track?  Could be an hour or more, and at 24/192, for example, storing raw PCM data for one track of that length would need more than 4 GB RAM (which is probably not addressable by the processor). 

Hope that helps,

Ian

[Hifi_swlon]

Thanks both, will have a read.... To my mind 2MB is a tiny buffer in this day and age though.

[f1eng]

The network activity annoys me too. I assume it is necessary for the remote apps to be able to switch the amp on more or less immediately, though.
Has anybody tried a configuration with the app remote control disabled to see if that stops it?

[iamwappie]

Taking the principle way of working the tracks is not streamed as ordinary data. In that case sending the data over a fast network connecting would indeed only take seconds. A virtual sound card is installed sending whatever is played on the host to the D in real time. So if the track being played is a 10 min track it will take 10 min to 'stream' which I guess kind of explains the busy network. From a network load perspective I'd say that this will be low.

[Hifi_swlon]

To my mind, knowing all that, it's no wonder Air doesn't work properly. Squillions of small, time critical parcels of data over a home network - purely from a common sense point of view seems designed to fail. The odds of something going wrong are surely multiplied to the nth degree. ....

I'm no expert of course, but being on the receiving end of pops, crackles, and throbbing noises of red book files running over Air on a fast network makes me feel for people trying to wifi hires files using this system.

[amabrok]

But then to operate otherwise, Devialet has to steer away from the virtual sound card approach which is by design forced to rely on small packets that simply stream what is playing on the source to a standalone app that is aware of what is being played to be able to buffer it in one go or on fewer but larger packets which will also requires a different hardware architecture in terms of internal buffer memory


Sent from my iPhone using Tapatalk

[f1eng]

But then to operate otherwise, Devialet has to steer away from the virtual sound card approach which is by design forced to rely on small packets that simply stream what is playing on the source to a standalone app that is aware of what is being played to be able to buffer it in one go or on fewer but larger packets which will also requires a different hardware architecture in terms of internal buffer memory


Sent from my iPhone using Tapatalk

Air version 1 was Mac/iTunes only and once de-bugged worked brilliantly. Apparently too many potential customers were anti iTunes, or Mac or both and it was completely re-written as version 2, which only shares the name not the concept, is universal and has not been satisfactorily de-bugged yet.
Very much not a case of "the customer is always right" IMO!

OTOH sending data down a wireless network is what wifi does and the idea that "common sense says it won't work" is technically ridiculous. Sorry.

[Jean-Marie]

But then to operate otherwise, Devialet has to steer away from the virtual sound card approach which is by design forced to rely on small packets that simply stream what is playing on the source to a standalone app that is aware of what is being played to be able to buffer it in one go or on fewer but larger packets which will also requires a different hardware architecture in terms of internal buffer memory


Sent from my iPhone using Tapatalk

Air version 1 was Mac/iTunes only and once de-bugged worked brilliantly. Apparently too many potential customers were anti iTunes, or Mac or both and it was completely re-written as version 2, which only shares the name not the concept, is universal and has not been satisfactorily de-bugged yet.
Very much not a case of "the customer is always right" IMO!

OTOH sending data down a wireless network is what wifi does and the idea that "common sense says it won't work" is technically ridiculous. Sorry.

While I agree that the way Air v1 was handling music was more satisfactory from an intellectual standpoint it was having a certain number of short comings amongst others:
1) Not being able to play protected files
2) Relying on a iTunes trick to keep track of what was playing and adjusting accordingly which was sometimes having some hiccups
3) The iTunes trick was not guarantied to work from version to version
4) streaming playing capabilities were limited to the internet radios (or the streams) that iTunes could play

Bottom line is that the virtual sound card, although certainly more difficult to make work correctly (and it is amusing to see that the Windows bug is not so far away from the Mac OS X bug that is also causing problem to air) is more generic.

I suspect, without having any proof point, that eventually Devialet may want to offer two alternate routes: 

1. The Virtual Card / Air: offering the maximum flexibility in terms of software playing and source etc... meaning that they delegate everything before the Air driven to non Devialet
   
2. The Dialog route where everything is under the Control and Responsibility of Devialet.
   

Jean-Marie