IEEE P 1722 technical issues and talking points

IEEE P 1722 technical issues and talking points Version 0. 01, 2007 -08 -21 Alan K. Bartky alan@snap-networks. com SNAP Networks Send comments to AVBTP@listserv. ieee. org 03 October 2020 IEEE P 1722 AVBTP Working Group Contribution 1

Notice of copyright release • Notice: – This document has been prepared to assist the work of the IEEE P 1722 and IEEE 802 Working Groups. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. • Copyright Release to IEEE: – The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by the IEEE P 1722 Working Group or the IEEE 802 Working Group. 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 2

gm_discontinuity / holdover • gm_discontinuity – Bump count on every discontinuity? • Picked for simplicity and to not have listeners need to have a timeout. • A step in time (no GM changes) does not need to have the talker set the hold – Bump only once until holdover cleared? • NO – Either? • NO • holdover – Maximum holdover time? • There is no maximum time for 802. 1 AS to stabilize. • This is dependency for us • There is a discussion going on in AS – Minimum holdover time? • We don’t believe there is a need to define in 1722 • If you step the time, the minimum could be zero. – Holdover time/timeout reset? – Timestamp field use during holdover – 802. 1 BA does not exist and won’t in our timeframe needs. We need to define the minimum accuracy for 802. 1 AS • 100 ppm • Talkers must be GM capable 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 3

Permanent holder over (h bit always 1) – A maximum time for AVBTP in addition to AS maximum time is required – Notes from meeting • • • AS time Detection of loss of GM 200 -300 ms Election of new grandmaster Wish from 1722 team: Keep max to 600 -700 ms Must be less than 1 second 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 4

Media clock Reset/discontinuity • Bit to indicate? – Proposal Toggle on change – Consensus this is a useful thing to add – Consensus if there is a toggle, there also must be a minimum time before you can toggle it again. • Tie into holdover bit? – No 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 5

Presentation time • Late presentation time – As normal case, with LP bit • Consensus to drop this bit from the spec – Occasional & permanently late time • Application specific 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 6

Data smoothing • Multiple packets per 8 k. Hz tick single stream • Multiple streams (smoothing across streams) • What does and what should 802. 1 Qav handle? – Qav will handle this and we don’t have to talk about this in 1722 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 7

Mandatory padding of 1722 frame • Should it be required? – No, Alan to change spec to remove this requirement 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 8

Deprecated 61883 types: • Summary of 61883 -6 support in AVB • Below is a preliminary list of supported and unsupported parts of the TA Document 2001024 Audio and Music Data Transmission Protocol 2. 1 for P 1722 audio end-stations. P 1722 Gateways may need to support any format available for maximum compatibility. 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 9

Deprecated 61883 types • These are recommendations for the minimal required support and are based on real world uses of the protocol on IEEE 1394 devices. Removal of support formats like DVD Audio may seem short sighted but DRM restrictions have made use of the format impractical and DVD players use the non-DRM version audio formats instead. The 32 bit floating point format is included even though there are no existing implementations using the format because new audio CODECS will support 32 bit floating point formatted audio directly and P 1722 should be prepared to stream the new format. 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 10

Supported 61883 -6 Event Types • 8. 1 AM 824 Data – 8. 1. 2 IEC 60958 Conformant Data – 8. 1. 3 Multi-bit Linear Audio (MBLA) – 8. 1. 5 MIDI Conformant Data – Allow mix of the above per 61883 -6 rules • 8. 2 32 -bit Floating Point Data • All the above agree to keep 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 11

Deprecated 61883 -6 Event Types • AM 824 options to be deprecated – – – – 8. 1. 1 Generic Format 8. 1. 4 One Bit Audio 8. 1. 6 SMPTE Time Code Data 8. 1. 7 Sample Count Data 8. 1. 8 High Precision Multi-bit Linear Audio 8. 1. 9 Ancillary Data 8. 1. 10 Application Specific Ancillary Data • 8. 3 24 -bit * 4 Audio Pack • All the above agree to deprecate • Matt to inform 1394 TA of our plans to support and deprecate 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 12

61883 timing • Is current method of “editing instructions” adequate? – Agreed this is an issue, especially for 61883 -6 over AVBTP. – Matt to start working on a contribution 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 13

“Gateway” / “IWU” • Which term to use • Details • Work on Annex B – Agreed single term is needed – Alan to ping Norm on thoughts on a name • Will copy AVBTP team – If no suggestion in 2 weeks, Editor’s discretion on picking new name, then we can re-visit 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 14

IIDC • Channel mapping – 31 on AVBTP – Current IIDC specifies only 0 to 15 for valid IDs – Same kind of “edit instructions” as done for 61883 series is needed – Additional work for Gateway/IWU for channel mapping • Alan to make fixes based on John’s comments 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 15

Q tagging and TPID field • MAAP protocol – Question: Should this be best effort instead of priority 6? • This standard will not specify nor recommend. – Will only specify – Protocol MAC address – Protocol Ethertype • Don and Michael to discuss this with Norm at the next 802 AVB meeting • Stream data – Can the bridge strip the TPID and VLAN field on sending to end stations for AVB streams? 03 October 2020 Bartky Networks www. bartky. net IEEE P 1722 AVBTP Working Group Contribution 16