This thread is to document findings and ideas about how the AIR streaming protocol works. It's based on examining network traffic between a Devialet and a host computer running the AIR software.
I started investigating this partly out of interest and partly to see whether I could work out what causes AIR to drop out occasionally (on my system). Please add your own ideas and findings, and correct anything you discover to be wrong. Hopefully between us we can build up a better picture of how AIR really works.
The protocol(s) used for discovery and remote control of the Devialet are not addressed here, and could be the topic of separate threads.
Disclaimer: I can't guarantee the accuracy of anything in this thread so use of the information is entirely at your own risk.
Initial data gathered using a 16-bit, 44.1 kHz stream. Host was a MacBook Pro running OS X 10.8.5, AIR 2.1.2, streaming to a Devialet 200 running firmware 7.1.1.
AIR uses the User Datagram Protocol (UDP) with unicast addressing.
The host transmits audio data from port 45456 to port 45455 on the Devialet. With 16/44 data, there's an outgoing packet about once every 4 ms. The payload length (excluding MAC, IP and UDP headers) is typically 962 bytes (giving a 1004-byte Ethernet packet). When the audio stream is idle (silent), the payload length drops to 166 bytes (208-byte Ethernet packet). This suggests AIR is implementing some form of compression at least in this simple case.
The Devialet transmits feedback/synchronisation information from port 45456 to host port 45456. With 16/44 data, there's an incoming packet (to the host) about once every 50 ms. The payload length seems to be a constant 41 bytes.
For a full 962-byte payload, the structure of the outgoing (host->Devialet) payload seems to be:
bytes 0-21 (22 bytes): payload header
bytes 22-426 (405 bytes): channel 1 audio header/data
bytes 427-831 (405 bytes): channel 2 audio header/data
bytes 832-833 (2 bytes): 16-bit CRC or other checksum?
bytes 834-961 (128 bytes): zero (padding?)
Total: 962 bytes
When the host is transmitting "silence", the payload becomes:
bytes 0-21 (22 bytes): payload header
bytes 22-28 (7 bytes): channel 1 audio header/data (all zero)
bytes 29-35 (7 bytes): channel 2 audio header/data (all zero)
bytes 36-37 (2 bytes): 16-bit CRC or other checksum?
bytes 38-165 (128 bytes): zero (padding?)
Total: 166 bytes
The payload header seems to be essentially the same for the "silence" case as the normal case. Discussed later.
Don't know yet which channel appears first in the payload (left, at a guess). Should be an easy experiment to find out, though.
I started investigating this partly out of interest and partly to see whether I could work out what causes AIR to drop out occasionally (on my system). Please add your own ideas and findings, and correct anything you discover to be wrong. Hopefully between us we can build up a better picture of how AIR really works.
The protocol(s) used for discovery and remote control of the Devialet are not addressed here, and could be the topic of separate threads.
Disclaimer: I can't guarantee the accuracy of anything in this thread so use of the information is entirely at your own risk.
Initial data gathered using a 16-bit, 44.1 kHz stream. Host was a MacBook Pro running OS X 10.8.5, AIR 2.1.2, streaming to a Devialet 200 running firmware 7.1.1.
AIR uses the User Datagram Protocol (UDP) with unicast addressing.
The host transmits audio data from port 45456 to port 45455 on the Devialet. With 16/44 data, there's an outgoing packet about once every 4 ms. The payload length (excluding MAC, IP and UDP headers) is typically 962 bytes (giving a 1004-byte Ethernet packet). When the audio stream is idle (silent), the payload length drops to 166 bytes (208-byte Ethernet packet). This suggests AIR is implementing some form of compression at least in this simple case.
The Devialet transmits feedback/synchronisation information from port 45456 to host port 45456. With 16/44 data, there's an incoming packet (to the host) about once every 50 ms. The payload length seems to be a constant 41 bytes.
For a full 962-byte payload, the structure of the outgoing (host->Devialet) payload seems to be:
bytes 0-21 (22 bytes): payload header
bytes 22-426 (405 bytes): channel 1 audio header/data
bytes 427-831 (405 bytes): channel 2 audio header/data
bytes 832-833 (2 bytes): 16-bit CRC or other checksum?
bytes 834-961 (128 bytes): zero (padding?)
Total: 962 bytes
When the host is transmitting "silence", the payload becomes:
bytes 0-21 (22 bytes): payload header
bytes 22-28 (7 bytes): channel 1 audio header/data (all zero)
bytes 29-35 (7 bytes): channel 2 audio header/data (all zero)
bytes 36-37 (2 bytes): 16-bit CRC or other checksum?
bytes 38-165 (128 bytes): zero (padding?)
Total: 166 bytes
The payload header seems to be essentially the same for the "silence" case as the normal case. Discussed later.
Don't know yet which channel appears first in the payload (left, at a guess). Should be an easy experiment to find out, though.
Roon (Mac Mini), Wilson Benesch Full Circle, Expert 1000 Pro CI, Kaiser Chiara
Warwickshire, UK
