The 1394 timestamp is used to convey a clock
(other than the 24.576 1394 clock itself) to
the receiver. For DV, the timestamp conveys
the video frame rate. For MPEG-2 the timestamp
conveys the system 27 MHz clock. For 1394 audio
(A&M protocol), the timestamp conveys the audio
sample clock.
Since this is generally an audio website, I'll
assume you're interested in A&M protocol. DV
and MPEG-2 timestamps are the same concept, but
the details are a bit different.
Here's a bus analyzer trace of a few A&M audio
packets. This is 44.1/16 PCM from the Pioneer
DV-47Ai. 44.1/16 is sent without encryption,
so the audio samples can be seen.
The first timestamp is 0x22be and the second
timestamp is 0x3828. 0x3828 - 0x22be = 0x156a.
However, the 1394 timestamp is really a bit
field composed of 12 bits 24.576 MHz ticks
modulo 3072, 13 bits of cycles modulo 8000 and
7 bits of seconds. So 0x156a is really 1386 +
3072 = 4458.
So there are 4458 24.576 MHz clock ticks between
the first sample of packet 1 and the first sample
of packet 2. 1/24576000 * 4458 = 181.396 microsec.
The number of samples in each packet is 8, so
the interval between 8 samples at 44100 Hz is
1/44100 * 8 = 181.405 microseconds.
That's the basic idea. Of course there's way
more implementation detail (like the empty packet
sent after the first two packets), but if you're
interested, I'll explain that in subsequent posts.
Ron
(other than the 24.576 1394 clock itself) to
the receiver. For DV, the timestamp conveys
the video frame rate. For MPEG-2 the timestamp
conveys the system 27 MHz clock. For 1394 audio
(A&M protocol), the timestamp conveys the audio
sample clock.
Since this is generally an audio website, I'll
assume you're interested in A&M protocol. DV
and MPEG-2 timestamps are the same concept, but
the details are a bit different.
Here's a bus analyzer trace of a few A&M audio
packets. This is 44.1/16 PCM from the Pioneer
DV-47Ai. 44.1/16 is sent without encryption,
so the audio samples can be seen.
Code:
TCODE OR QUADDATA
STORE# EVENT TYPE SPD MSB LSB CNT DESCRIPTION FIELD TIMESTAMP
000000 CYCLE_START 100 FFFF008F 01 DEST=3FF:3F TL=00 RT=0 PRI=F 0.000 US
000001 ASYNC 100 FFC3FFFF 02 SRC= 3FF:03 0.330 US
000002 ASYNC 100 F0000200 03 DEST_OFFST=CSR: CYCLE_TIME 0.320 US
000003 ASYNC 100 F2650024 04 CYCLE TIME 0.330 US
000004 ASYNC 100 BF764C16 05 HEADER CRC 0.320 US
000005 ISO_DATABLK 100 00487FA2 01 LENGTH=0048 CHNL=7F SYNC=2 1.100 US
000006 ISO 100 748BF64D 02 HEADER CRC 0.330 US
000007 ISO 100 03020060 03 0.320 US
000008 ISO 100 900122BE 04 SYT = 0x22be 0.330 US
000009 ISO 100 18E20E00 05 0.320 US
000010 ISO 100 00E5B600 06 0.330 US
000011 ISO 100 18DCB700 07 0.320 US
000012 ISO 100 00E1CF00 08 0.330 US
000013 ISO 100 10D70000 09 0.330 US
000014 ISO 100 02DB4900 10 0.320 US
000015 ISO 100 1AD38300 11 0.330 US
000016 ISO 100 08D87A00 12 0.320 US
000017 ISO 100 10D07300 13 0.330 US
000018 ISO 100 08D80700 14 0.320 US
000019 ISO 100 18CA4600 15 0.330 US
000020 ISO 100 00D59400 16 0.320 US
000021 ISO 100 18C37000 17 0.330 US
000022 ISO 100 00D36700 18 0.330 US
000023 ISO 100 10C04700 19 0.320 US
000024 ISO 100 08D4E600 20 0.330 US
000025 ISO 100 8347D14E 21 0.320 US
000026 SUBACTN GAP 100 10.83 US
000027 ARB GAP 100 10.49 US
000028 CYCLE_START 100 FFFF008F 01 DEST=3FF:3F TL=00 RT=0 PRI=F 94.77 US
000029 ASYNC 100 FFC3FFFF 02 SRC= 3FF:03 0.330 US
000030 ASYNC 100 F0000200 03 DEST_OFFST=CSR: CYCLE_TIME 0.320 US
000031 ASYNC 100 F2651024 04 CYCLE TIME 0.330 US
000032 ASYNC 100 AF27D705 05 HEADER CRC 0.320 US
000033 ISO_DATABLK 100 00487FA2 01 LENGTH=0048 CHNL=7F SYNC=2 1.100 US
000034 ISO 100 748BF64D 02 HEADER CRC 0.330 US
000035 ISO 100 03020068 03 0.320 US
000036 ISO 100 90013828 04 SYT = 0x3828 0.330 US
000037 ISO 100 18C13A00 05 0.320 US
000038 ISO 100 02DB0800 06 0.330 US
000039 ISO 100 12C4B100 07 0.320 US
000040 ISO 100 00DF7F00 08 0.330 US
000041 ISO 100 10C5CA00 09 0.330 US
000042 ISO 100 08E19700 10 0.320 US
000043 ISO 100 18CA9D00 11 0.330 US
000044 ISO 100 00E6BA00 12 0.320 US
000045 ISO 100 10D23F00 13 0.330 US
000046 ISO 100 08EA2D00 14 0.320 US
000047 ISO 100 10D77D00 15 0.330 US
000048 ISO 100 08EA8400 16 0.320 US
000049 ISO 100 30D7B400 17 0.330 US
000050 ISO 100 0AE9EA00 18 0.330 US
000051 ISO 100 12D6B400 19 0.320 US
000052 ISO 100 08EAA500 20 0.330 US
000053 ISO 100 8234C6F4 21 0.320 US
000054 SUBACTN GAP 100 10.83 US
000055 ARB GAP 100 10.49 US
000056 CYCLE_START 100 FFFF008F 01 DEST=3FF:3F TL=00 RT=0 PRI=F 94.77 US
000057 ASYNC 100 FFC3FFFF 02 SRC= 3FF:03 0.320 US
000058 ASYNC 100 F0000200 03 DEST_OFFST=CSR: CYCLE_TIME 0.330 US
000059 ASYNC 100 F2652024 04 CYCLE TIME 0.330 US
000060 ASYNC 100 9FD57A30 05 HEADER CRC 0.320 US
000061 ISO_DATABLK 100 00087FA2 01 LENGTH=0008 CHNL=7F SYNC=2 1.100 US
000062 ISO 100 02A0D78D 02 HEADER CRC 0.330 US
000063 ISO 100 03020070 03 0.320 US
000064 ISO 100 9001FFFF 04 0.330 US
000065 ISO 100 CDA82563 05 0.320 US
000066 SUBACTN GAP 100 10.83 US
000067 ARB GAP 100 10.49 US
000068 CYCLE_START 100 FFFF008F 01 DEST=3FF:3F TL=00 RT=0 PRI=F 99.98 US
000069 ASYNC 100 FFC3FFFF 02 SRC= 3FF:03 0.330 US
000070 ASYNC 100 F0000200 03 DEST_OFFST=CSR: CYCLE_TIME 0.320 US
000071 ASYNC 100 F2653024 04 CYCLE TIME 0.330 US
000072 ASYNC 100 8F84E123 05 HEADER CRC 0.320 US
000073 ISO_DATABLK 100 00487FA2 01 LENGTH=0048 CHNL=7F SYNC=2 1.100 US
000074 ISO 100 748BF64D 02 HEADER CRC 0.330 US
000075 ISO 100 03020070 03 0.320 US
000076 ISO 100 90015192 04 0.330 US
000077 ISO 100 10DA5D00 05 0.320 US
000078 ISO 100 08EB6D00 06 0.330 US
000079 ISO 100 18DA1700 07 0.330 US
000080 ISO 100 00EBBB00 08 0.320 US
000081 ISO 100 10D48B00 09 0.330 US
000082 ISO 100 08ED9200 10 0.320 US
000083 ISO 100 10D05700 11 0.330 US
000084 ISO 100 00EE2E00 12 0.320 US
000085 ISO 100 18D13200 13 0.330 US
000086 ISO 100 0AEF8C00 14 0.320 US
000087 ISO 100 10D09700 15 0.330 US
000088 ISO 100 00EF1F00 16 0.320 US
000089 ISO 100 14C9DC00 17 0.330 US
000090 ISO 100 0CEAE600 18 0.330 US
000091 ISO 100 10C7D900 19 0.320 US
000092 ISO 100 08EA7800 20 0.330 US
000093 ISO 100 6D51EAD2 21 0.320 US
000094 SUBACTN GAP 100 10.83 US
000095 ARB GAP 100 10.49 UStimestamp is 0x3828. 0x3828 - 0x22be = 0x156a.
However, the 1394 timestamp is really a bit
field composed of 12 bits 24.576 MHz ticks
modulo 3072, 13 bits of cycles modulo 8000 and
7 bits of seconds. So 0x156a is really 1386 +
3072 = 4458.
So there are 4458 24.576 MHz clock ticks between
the first sample of packet 1 and the first sample
of packet 2. 1/24576000 * 4458 = 181.396 microsec.
The number of samples in each packet is 8, so
the interval between 8 samples at 44100 Hz is
1/44100 * 8 = 181.405 microseconds.
That's the basic idea. Of course there's way
more implementation detail (like the empty packet
sent after the first two packets), but if you're
interested, I'll explain that in subsequent posts.
Ron
Hi,
Thanks a lot for your comprehensive answer.
But one thing which I am still unclear about is
how to extract a sampling clock frequency from
the received audio packet. (Packet sent on the
1394 bus has a time stamp on it. How do I extract
the sampling clock freq. using this time stamp ?)
Thanks again.
Thanks a lot for your comprehensive answer.
But one thing which I am still unclear about is
how to extract a sampling clock frequency from
the received audio packet. (Packet sent on the
1394 bus has a time stamp on it. How do I extract
the sampling clock freq. using this time stamp ?)
Thanks again.
A way is needed to relate the 24.576 MHz 1394
clock (which by default is the same at all
nodes) to your local audio sampling clock. The
easiest way to do this is to have the value
of the 1394 clock latched at some interval by
the local audio clock. This is not a feature
you'll see on any general purpose 1394 LLC,
but keep reading. The TI TSB43CB43A has some
kind of clock recovery support, but I'm not
sure exactly how it works.
http://focus.ti.com/docs/prod/folders/print/tsb43ca43a.html
Now it's know how many 1394 clocks are in x amount
of local audio samples. In my post example, the
1394 timestamps are telling us that there are
4458 1394 clocks for every 8 samples. If the
1394 clock value is latched every 8 samples with
the local audio clock, the difference between
successive latched 1394 clock values will be
somewhere around 4458.
By using a VCXO for the local audio clock, the CPU
can change the frequency (measured in 1394 clocks)
to match the timestamps. It's a "software PLL"
so to speak. A low-pass filter on the timestamp
values is required to eliminate the large
inherent jitter (1/24576000 = 40 nanosecond,
which is a lot).
Here's a very well written paper on 1394 clock
recovery jitter:
http://www.nanophon.com/audio/1394_sampling_jitter.pdf
In that paper, one of the solutions offered is
in section 8.4.5 and is what is being used by
the current 1394 implementations by Pioneer,
Sony, Denon and Yamaha. Instead of the receiver
trying to recover the sampling clock, the
receiver controls the rate of transmission from
the source with a rate control protocol sent over
the very same 1394 bus. The receiver use a fixed
rate sample clock (which can be a high quality,
low-jitter crystal oscillator) and just monitors
the level of it's receive packet buffer. If an
upper threshold is hit, the receiver sends a
"SLOW" rate control request to the source.
Likewise, if a lower threshold is hit, the
receiver sends a "FAST" rate control request.
Since the rate of change in the buffer level
is quite slow (that is, the phase of the player
and receiver clocks are not that far off to begin
with), this scheme works fantastically well.
The manufacturers all have their own name for
this protocol. Pioneer calls it PQLS, Sony calls
it HATS and Denon has yet another name. The
real specification is called "AV/C Command Set
for Rate Control of Isochronous Data Flow 1.0"
which is an open specification available from
the 1394 Trade Association:
http://1394ta.org
Unfortunately, the specifications can be
downloaded by 1394ta members only.
So the ultimate solution to the clock recovery
problem is to not do it.
Ron
clock (which by default is the same at all
nodes) to your local audio sampling clock. The
easiest way to do this is to have the value
of the 1394 clock latched at some interval by
the local audio clock. This is not a feature
you'll see on any general purpose 1394 LLC,
but keep reading. The TI TSB43CB43A has some
kind of clock recovery support, but I'm not
sure exactly how it works.
http://focus.ti.com/docs/prod/folders/print/tsb43ca43a.html
Now it's know how many 1394 clocks are in x amount
of local audio samples. In my post example, the
1394 timestamps are telling us that there are
4458 1394 clocks for every 8 samples. If the
1394 clock value is latched every 8 samples with
the local audio clock, the difference between
successive latched 1394 clock values will be
somewhere around 4458.
By using a VCXO for the local audio clock, the CPU
can change the frequency (measured in 1394 clocks)
to match the timestamps. It's a "software PLL"
so to speak. A low-pass filter on the timestamp
values is required to eliminate the large
inherent jitter (1/24576000 = 40 nanosecond,
which is a lot).
Here's a very well written paper on 1394 clock
recovery jitter:
http://www.nanophon.com/audio/1394_sampling_jitter.pdf
In that paper, one of the solutions offered is
in section 8.4.5 and is what is being used by
the current 1394 implementations by Pioneer,
Sony, Denon and Yamaha. Instead of the receiver
trying to recover the sampling clock, the
receiver controls the rate of transmission from
the source with a rate control protocol sent over
the very same 1394 bus. The receiver use a fixed
rate sample clock (which can be a high quality,
low-jitter crystal oscillator) and just monitors
the level of it's receive packet buffer. If an
upper threshold is hit, the receiver sends a
"SLOW" rate control request to the source.
Likewise, if a lower threshold is hit, the
receiver sends a "FAST" rate control request.
Since the rate of change in the buffer level
is quite slow (that is, the phase of the player
and receiver clocks are not that far off to begin
with), this scheme works fantastically well.
The manufacturers all have their own name for
this protocol. Pioneer calls it PQLS, Sony calls
it HATS and Denon has yet another name. The
real specification is called "AV/C Command Set
for Rate Control of Isochronous Data Flow 1.0"
which is an open specification available from
the 1394 Trade Association:
http://1394ta.org
Unfortunately, the specifications can be
downloaded by 1394ta members only.
So the ultimate solution to the clock recovery
problem is to not do it.
Ron
- Status
- Not open for further replies.