November 2001 meeting of SC-02-02

Chair J. Dunn convened the meeting. The agenda and the report from the previous meeting were approved as written except that a correction was made in fourth paragraph of discussion of project AES-X119 which should begin "It should not be ... ."

Current development projects

AES3-R Revision of AES3-1992 (r1997) AES Recommended practice for digital audio engineering -- Serial transmission format for two-channel linearly represented digital audio data

A secretariat-prepared PWD for revision of AES3 had been posted on the FTP site two months prior to the meeting and there has been no resulting discussion on the e-mail reflector. The draft is intended to conform to current AESSC style based on the IEC directives for the preparation of standards. All changes are editorial.

Three documents have been presented to the WG proposing new drawings for the example of a general circuit configuration (figure 6 of AES3-1992). They were produced by C. Travis, J. Brown, and S. Scott. The figure is informative. The main issues raised were the inclusion of a receiver termination, and the connection of cable screen to the chassis (rather than some internal circuit ground trace).

In addition there was concern about implying the use of transformers is required, and the circuit changes needed when using very low cost transformers. Scott proposed two figures, illustrating implementations with and without transformers. In both cases there are d.c. blocking capacitors to ensure no d.c. path between the signal conductors, and no d.c. path from the signal conductors to anything else.

The Travis proposal was for one figure with minimal changes from the current figure. It adds a termination resistor across the two signal conductors at the receiver side and shows the cable screens connections only connecting to the chassis at each end of the interface.

Brown proposed a figure and associated text. On it, transformers, capacitors, and resistors are replaced by a driving-network box at the driver end of the cable and a termination-isolation-network box at the receiving end.

The chair suggested that the conclusion of the group may be to create an informative annex for this example circuit. This would make it more obvious that the circuit was not part of the specification and would also allow more space for text. It is also possible that the information could be moved to AES-2id.

Discussion of this circuit continues on the WG e-mail reflector. It was noted that this issue affects similar work being undertaken in IEC MT60958-4.

AES-2id-R Review of AES-2id-1996 AES information document for digital audio engineering -- Guidelines for the use of the AES3 interface

It was noted that some of the discussion on project AES3-R may have an impact on this project.

No action was required.

AES-10id-R Review of AES-10id-1995 AES information document for digital audio engineering -- Engineering guidelines for the multichannel audio digital interface (MADI) AES10

R. Caine will review the document and highlight any parts that appear to need revision as a result of updating AES10.

AES10-R Review of AES10-1991 (r1997) AES recommended practice for digital audio engineering -- Serial multichannel audio digital interface (MADI)

The last meeting decided to try to resolve the comment by V. Recipon on the CFC without introducing a substantive change. This had proven to be not possible so the draft was returned to the WG which assigned it to task group SC-02-02-D. A PWD is to be reported by the task group with a target date of 2002-02.

A CFC for reaffirmation is in process.

No action required.

The group noted that IEC61883-6 and the AES-X92 project can both carry AES3 formatted data so this project is topical but resources are not available to complete it. The WG is requesting suspension of the project.

The secretariat has recently produced a PCFC based on the task group document which is now in the WG for consideration. The group decided to return the document to the task group in two weeks after the WG has been given time to identify any items that need more work. It was noted that this standard is being driven by a user, the BBC, who need it developed urgently. Many of the manufacturers known to be developing audio over ATM do not appear to be active participants in the project or, or at least have not joined the task group.

The group is requesting suspension of this project.

C. Chambers initiated the project and posted a draft requirements specification and an updated project definition on the working group e-mail reflector on 2001-08-17. Caine suggested, in view of project AES-X114 assigned to SC-06-06, that project AES-X111 may result only in providing a flag in AES3 channel status so that, for example, the user data channel could be identified as being used for carrying the data defined in project AES-X114.

The group agreed to form a task group to prepare a draft amendment to AES3. The chair proposed that Chambers as convenor.

AES-X119 Connector for AES3 interfaces

The convenor of the task group to which the project is assigned has resigned.

Brown presented a block diagram to illustrate analogue cabling infrastructure in a live performance venue. The diagram illustrates a problem with mixing digital and analogue signals on the same connectors. Cable lengths of up to 500 feet, and of mixed impedance, are used for the infrastructure but will not work reliably with digital signals.

Caine suggested that the task group consider whether the connector known as the XLD is to be incorporated into AES3 as an option or as a replacement for the XLR, or not be used at all. A. Eckart pointed out that AES42 describes a new connector (the XLD) that is not yet in production. He suggested that if this was only made an optional connector in AES3 then people would not bother to adopt the XLD and so it would not be produced.

Eckart considered that it was unfortunate that the AES42 specification of a digital interface for microphones includes specifics about the proposed XLD connector because SC-05-02 is to specify the connector. J. Nunn pointed out that the AES42 specification does not detail the connector, but only portrays it general appearance and use.

Brown advocated that the XLD be made a requirement for all newly designed products with AES3 interfaces. Caine countered that the XLD connector should be only an alternative and not a replacement for the XLR for digital applications.

Caine pointed out that connector specification details are not in the scope of SC-02-02 but the group can discuss the use of the proposed XLD. However, the group needs to see some detail from SC-05-02.

Nunn reminded the group that the reason SC-02-02 is involved in the discussion of this proposed XLD connector before it has been specified by SC-05-02 is to provide assurance that the connector was needed and would be used. This assurance would provide encouragement for manufacturers to develop it and the specification required by SC-05-02. For this to happen there would need to be some assurance that the XLD would be permissible for use with AES3.

The chair advised the group that S. Harris had resigned as the leader of the task group, SC-02-02-F, and that the task group was looking for a new leader. Brown volunteered.

The discussion ended with a series of questions about the XLD being proposed to the task group. For equipment with AES3 interfaces, is it forbidden, permitted, preferred, optional, or required? Should it always, or optionally, be supplied with removable keys to allow it to become intermateable with the XLR? If XLDs with removable keys are supplied should it be required that equipment is supplied with the keys present?

New Business

IEC 60958-4 is the IEC document parallel to AES3. Its latest draft, 100/396/CDV, is currently out for vote. AES can propose a new diagram for figure 1 in that standard to be similar to the latest draft from project AES3-R.

The IEC document is at the last stage, committee draft for voting (CDV), during which new input can be provided but it can only be informative. It was agreed that a response of WG experts would be discussed on the reflector.

[Secretariat note: The IEC was informed of the new diagram.]

A. Mason asked that a copy of ITU-T V.11 be obtained for the WG. It is referenced in both the IEC and AES standards. It may address some of the concerns with regard to IEC60958-4 and AES3 in connection with the example circuit.

IEC 60958-1 maintenance is being initiated. The document MT60958-1(Dunn/Yoshio)20011220 contains a draft being prepared for circulation as a committee draft (CD) for amendment or revision of this document. This was based on the document presented to the previous meeting of SC-02-02. Yoshio-san gave some explanation of the development of the text since that meeting.

Four new informative annexes are being proposed:

a) to clarify the relationship between various application standards and the state of the first two channel status bits;

b) to show how the application standards relate to each other;

c) to indicate a potential problem with Compact Discs that are encoded with non-linear pulse-code modulation data;

d) to reference the other application standards using IEC60958.

Nunn asked that a mechanism be developed to prepare an working group response because some of the new annexes can be very controversial. M. Yonge reported on a meeting he had with the secretary of IEC TC100/TA4 responsible for IEC60958 maintenance. He gave an outline of how liaison may be developed so that liaison is between experts and where expert opinion is required there should be joint membership of groups.

New projects

No project requests were received or introduced.

The next meeting is scheduled to be held in conjunction with the AES 112th Convention in Munich, Germany.

For more information about standards activity: [email protected]

Back to AESSC Meeting Reports