At 188.8.131.52 Intrinsic Jitter is specified as "Peak" value /0.025 UI/ whilst at point 8.3.6 Receiver Jitter Tolerance is specified as "Peak-to-Peak" . Because this difference often results in confusion I propose to harmonize these two results - either both to "Peak" or (this is easier) both to "Peak-to-Peak".
Secondly, it is also desirable to maintain the same wording as IEC 60958-4 where the values of same parameters are specified.
After careful consideration of inputs from both Chris Travis and Keith Kondakor, I believe it is better to leave the wording as is, but perhaps add a note referring to the probable assymetry of the receiver jitter tolerance.
The advantage of this solution is that the difference in the character of the parameters is emphasised.
I propose a note under 184.108.40.206, preceding existing Notes 1 and 2 which would be renumbered as 2 and 3.
"Note 1. This jitter may be strongly asymmetric in character, and the deviation from the ideal timing should meet the specification in either direction."Adding such a note is not a substantive change, and I trust this is sufficient to continue with the process.
Regards, Robin Caine
Thank you for your answer. Let me comment once more my different opinion.
1) You wrote about a "asymmetry of the RECEIVER jitter tolerance but spoke the same time of point 220.127.116.11 which is the TRANSMITTER Output jitter. What exactly do you mean?
2) As far as I know, there is no measurement equipment which is able to measure the asymetry of the jitter or generate an asym. jitter (I am familiar with AudioPrecision S2, S2C, Rhode and Schwarz UPD, UPL, PrismSound DSA1 and Neutrik A2D).
3) The difficulty for all measurement-technicians is, that the eqiupment of AudioPrecision and Rhode and Schwarz generates and measure PEAK-Jitter whilst DSA-1 works with PEAK-to-PEAK Jitter and I heard, that in future PrismSound will change this to PEAK.
Now you are going to publish a new version of AES3 in which you mix Peak-specifications and peak-to-peak-spec. This is what I meant with "confusion" .
Please consider, that all papers you create (AES3, AES11, AES17 etc.) are well known here and should used by all technicians (only a very few are engineers!) in the measurement and design groups and therefore they expect clear and understandable specifications and notes.
Firstly, all the test equipment that you mention, (and many others) were designed to test to AES3-1992. The relevant clauses are unchanged in this draft revision; also we have had no comment from any designer of such equipment asking to change these clauses.
The jitter mechanism in the transmitter is a quite different matter from the specifying of a tolerance in the receiver. The first is anything but symmetrical and must be limited to a peak value in either direction, whereas a tolerance in the receiver can be whatever we like - naturally we chose a symmetrical requirement, which can be defined equally by peak or peak-to-peak.
It was not our intention in this revision to change anything substantive in the area of jitter measurement and my greatest fear is that any change to the existing wording is more likely to cause more confusion than keeping it intact.
I accept that the peak-to-peak figure is nominally twice the single peak value, and that such a change may be consistent with the intent of the standard, but it would be a 'substantive change' to the document and we cannot do that without discussion and a clear and considered consensus for it.
Your point is noted, and will of course be included for discussion in the next revision. I hope this explanation will satisfy your concerns.
Robin Caine for SC-02-02Secretariat note:
The revision of AES3 is overdue and it is important that it is concluded as soon as possible. Working Group SC-02-02 has stated that, in the interests of time pressure, this revision has been deliberately kept simple and that a further and deeper revision of AES3 is intended as soon as practical. I must be clear: changing clause 18.104.22.168 to specify (for example) a peak-to-peak jitter of 0,05 UI will require a fresh formal procedure to agree a new draft, according to our rules, and this will add many months to the progress of AES3.
Please note that all standards documents are regularly reviewed and may be amended or revised at any time as need arises. A formal review of each AES standards document is required at maximum intervals of five years.
Also, on investigation, I note that the points you mention were raised previously in the context of AES17 in the Working Group SC-02-01 (but not, unfortunately, in SC-02-02). AES17-1998 is also due for review this year and it may be appropriate to raise this matter for discussion in that context; the consensus arising from such a discussion involving measurement experts would then be more straightforward to incorporate into the subsequent revision of AES3.