Report of the meeting of the SC-02-02 working group on digital audio interfaces, of the subcommittee on digital audio, held in San Francisco, CA., US., on 2012-04-26
The meeting was convenened by chair J. Grant.
The agenda was approved as written.
The report of the previous meeting, under project X182, referred to the question of whether Ethernet transformers would perform well enough "at lower frequencies to pass AES3 signals"; that should read "at low temperatures". There having been no other issues raised via the e-mail reflector or at the meeting, the report as amended is approved.
AES5-R Review of AES5-2008: AES recommended practice for professional digital audio - Preferred sampling frequencies for applications employing pulse-code modulation
S. Lyman reported that SMPTE does make normative reference to AES5. This standard is due for review in 2013, so any proposals for amendment should be raised now.
AES10-R Review of AES10-2008: AES Recommended Practice for Digital Audio Engineering - Serial Multichannel Audio Digital Interface (MADI)
This standard is also due for review in 2013. S. Heinzmann pointed out that the numbers of channels listed in the Abstract do not match those in clause 5. The question of whether varispeed is still used was raised; S. Flock reported that it is still used to avoid the processing that would otherwise be required to change the pitch of recorded material, where there are a large number of channels or where it would significantly impact the audio quality. See also "new business" below.
AES11-R Review of AES11-2009: AES Recommended Practice for Digital Audio Engineering - Synchronization of digital audio equipment in studio operations
Heinzmann proposed new text for subclause 5.2 which was accepted by the meeting. There may be further amendments required as a result of AES-X186C (see below), in which case both should be done together.
AES41-R: Review of AES41-2009: AES standard for digital audio - Recoding data set for audio bit-rate reduction
The 2012 version has now been published, in 5 separate parts.
AES55-R: Review of AES55-2007: AES standard for digital audio engineering - Carriage of MPEG Surround in an AES3 bitstream
A secretariat-formatted text was uploaded to the document area on 8th August 2012. The Chair has now requested WG approval of this draft (see e-mail of 27th October 2012).
AES-2id-R: Review of AES-2id-2006: AES information document for digital audio engineering - Guidelines for the use of the AES3 interface
The revised AES-2id-2012 was recently published.
AES-R8: AES standards project report - Synchronisation of digital audio over wide areas
Grant to propose text for 3.2 and/or 2.4 to point out that if separate interfaces receiving audio data over an asynchronous network contribute to the same sound field then measures must be taken to prevent them drifting relative to each other in time.
AES-X182: AES/Ethernet Simple Open Protocol
A revised draft was uploaded to the TG document area on 26th October 2012 (filename x182-ptd-zanghieri-121024.pdf, changed text in red); subject to formal approval by the TG, it will be presented to the WG as a PWD. Note that WG members can access TG documents via the TG directory in the WG document site.
AES-X186A,B,C: Liaisons with ITU-R re drafts derived from AES10-2008, AES3-2009, and AES11
The Secretariat reported that no input had been received from ITU-R. K. Hamasaki reported that a liaison had been sent re X186C, and forwarded a copy of it to the Secretariat after the meeting.
AES-X196: Use of AES3 with high sampling rates to carry multi-channel audio (Note: the title has been changed to avoid giving the impression that it is intended to change AES3)
There are two proposed options for identifying the channels: (a) use Y preamble for all channels except the first; and (b) set the C bit in the second subframe of a frame to 1 for the last channel, 0 otherwise. Currently, there is no consensus on which to use. P. Treleaven observed that TG SC-02-02-K had been set up to enquire of EBU members and router manufacturers which of these options would work with their systems, and there does not appear to have been any progress on that. E. Simon offered that one of his students could produce some audio files to be used in tests.
New business:
MADI over twisted-pair cable
M. Brunke presented the proposal for MADI over twisted pair using Ethernet PHY chips which has been offered to SC-02 (see Chair's e-mail of 23rd October 2012). The format on the cable has to be different from that for co-ax, using MLT3 coding (with scrambling) instead of NRZI, but when passed through standard Ethernet copper-to-fibre convertors it is compatible with the current MADI fibre format. Whereas 4.3.2 of the current AES10 allows single sync symbols to be inserted between subframes, the Ethernet PHYs require longer sequences of sync (or idle) symbols, so for compatibility with them the new format will require the sync symbols to be collected together, probably specifying that they may only appear between frames.
Assuming SC-02 allocates the project to SC-02-02, a new TG will be formed, chaired by Brunke, to propose either additions to AES10 or a companion standard, to include both 100 Mb/s over twisted pair and 1 Gb/s.
The meeting closed at 16:35.
The next meeting will be held in conjunction with the 134th Convention in Rome.
Operational note: Remote participation worked surprisingly well, though there were a few occasions where dropouts etc became noticeable. The Chair was using Skype over a fast (60 Mb/s download Virgin Cable) Internet connection with no video, and testing earlier in the day with a slower connection (14 Mb/s download ADSL, still faster than the UK average) seemed to have more dropouts, though that may have been because video was enabled for some of the time. He used two screens, one of which was shared with the meeting room and displayed on the projector; running the meeting with a single screen would have been difficult. There were noticeable (but bearable) delays in updating the screen. Some participants were barely audible, which may have been due to Skype using the wrong audio source. There were no problems with echo. Video from the meeting room would have been useful at some points in the meeting, but not if it would take up bandwidth that could be better used by the audio.
