07-Sep-2014, 15:48
The 41-byte payload for incoming (Devialet->host) packets seems to be:
byte 0 (1 byte): 0x44 ('D' for Devialet?)
byte 1 (1 byte): 0x66 ('f' for feedback?)
bytes 2-5 (4 bytes): stream ID (as in outgoing packets)
bytes 6-9 (4 bytes): 0x00 0x00 0x00 0x02
bytes 10-13 (4 bytes): possibly high-order 32 bits of sequence number?
bytes 14-17 (4 bytes): (low order 32 bits of) sequence number 1
bytes 18-21 (4 bytes): possibly high-order 32 bits of sequence number?
bytes 22-25 (4 bytes): (low order 32 bits of) sequence number 2
bytes 26-29 (4 bytes): possibly high-order 32 bits of sequence number?
bytes 30-33 (4 bytes): (low order 32 bits of) sequence number 3
bytes 34-38 (5 bytes): zero
bytes 39-40 (2 bytes): 16-bit CRC or other checksum?
The four-byte sequence 00 00 00 02 might be correlated with the four bytes with the same value at offset 7-10 in the outgoing packets?
The three sequence number values each increment in successive feedback frames.
By correlating the outgoing data frames and the feedback frames, it looks to me as though the first of the sequence number values is the sample number for the most recent sample the Devialet has received from the host. (That may not be from the previous outgoing data packet on the wire, of course.)
The second sequence number value seems always to be 199 below the first one. That suggests it's the first sequence number in the most recently received payload. If that were true it seems it's redundant to have both this and the first value, so I suspect there must be some reason why both are present (possibly detection of packet loss or out-of-order delivery?).
The third sequence number doesn't directly correlate with values seen in the outgoing packets. The difference between this value in consecutive feedback packets is always 2,205 (plus or minus one) in my tests - at a 44.1 kHz sample rate this corresponds to exactly 50 ms which suggests it's probably locked to the audio playback pipeline in the Devialet and provides a timebase for generating the data for these feedback frames. It looks like this is how AIR synchronises (in the long term) with differences between the Devialet's internally-derived sample rate and whatever generates the sample rate on the host.
This third value stays roughly in step with the first two values, but in my tests was consistently about 62,000-64,000 below them. At a 44.1 kHz sample rate that corresponds to a time delay of about 1.4 seconds. This might relate to the "target device buffer" depth which was set at 1000 ms in my tests.
I've attached a screen shot of the packet capture, although there's not much to see:
byte 0 (1 byte): 0x44 ('D' for Devialet?)
byte 1 (1 byte): 0x66 ('f' for feedback?)
bytes 2-5 (4 bytes): stream ID (as in outgoing packets)
bytes 6-9 (4 bytes): 0x00 0x00 0x00 0x02
bytes 10-13 (4 bytes): possibly high-order 32 bits of sequence number?
bytes 14-17 (4 bytes): (low order 32 bits of) sequence number 1
bytes 18-21 (4 bytes): possibly high-order 32 bits of sequence number?
bytes 22-25 (4 bytes): (low order 32 bits of) sequence number 2
bytes 26-29 (4 bytes): possibly high-order 32 bits of sequence number?
bytes 30-33 (4 bytes): (low order 32 bits of) sequence number 3
bytes 34-38 (5 bytes): zero
bytes 39-40 (2 bytes): 16-bit CRC or other checksum?
The four-byte sequence 00 00 00 02 might be correlated with the four bytes with the same value at offset 7-10 in the outgoing packets?
The three sequence number values each increment in successive feedback frames.
By correlating the outgoing data frames and the feedback frames, it looks to me as though the first of the sequence number values is the sample number for the most recent sample the Devialet has received from the host. (That may not be from the previous outgoing data packet on the wire, of course.)
The second sequence number value seems always to be 199 below the first one. That suggests it's the first sequence number in the most recently received payload. If that were true it seems it's redundant to have both this and the first value, so I suspect there must be some reason why both are present (possibly detection of packet loss or out-of-order delivery?).
The third sequence number doesn't directly correlate with values seen in the outgoing packets. The difference between this value in consecutive feedback packets is always 2,205 (plus or minus one) in my tests - at a 44.1 kHz sample rate this corresponds to exactly 50 ms which suggests it's probably locked to the audio playback pipeline in the Devialet and provides a timebase for generating the data for these feedback frames. It looks like this is how AIR synchronises (in the long term) with differences between the Devialet's internally-derived sample rate and whatever generates the sample rate on the host.
This third value stays roughly in step with the first two values, but in my tests was consistently about 62,000-64,000 below them. At a 44.1 kHz sample rate that corresponds to a time delay of about 1.4 seconds. This might relate to the "target device buffer" depth which was set at 1000 ms in my tests.
I've attached a screen shot of the packet capture, although there's not much to see:
Roon (Mac Mini), Wilson Benesch Full Circle, Expert 1000 Pro CI, Kaiser Chiara
Warwickshire, UK
