IEEE 1722.1 Agenda 20190501 AVBTP-DECC@LISTSERV.IEEE.ORG AVBTP@LISTSERV.IEEE.ORG Meeting time is 9AM Pacific Daylight Time (GMT -7) In advance of joining the meeting, please review the Essential Patent Claims Announcement https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf The policies and procedures for this group can be found here: http://grouper.ieee.org/groups/1722/1/web/P1722_1_WG_PP.pdf Online Zoom Meeting address for this week: https://zoom.us/j/2268818568 One tap mobile +14086380968,,2268818568# US (San Jose) +16699006833,,2268818568# US (San Jose) Dial by your location +1 408 638 0968 US (San Jose) +1 669 900 6833 US (San Jose) +1 646 876 9923 US (New York) Meeting ID: 226 881 8568 Find your local number: https://zoom.us/u/cMjKFMQnr This week has proposals for the two issues discussed last week. The discussion will be on how to best vet them and move them to a ballot. The important criteria to meet are preserving backwards compatibility and meeting the needs of the pro-audio community that has deployed AVB in their devices. Item 1. How to best constrain the list of connected listeners a talker shall maintain. The current 1722.1 does not mandate a size for the list. Is 0 a valid size for the list? Proposal: 1. Define a legal range of sizes for the connected_listeners array maintained by a Talker. The existing spec does not explicitly specify an upper or lower bound for the size of the connected_listeners array. The connection_count field is 16 bits, which implies an upper bound of 65535 entries in the array. Each entry in the array takes up 10 bytes (8 bytes for listener_entity_id, 2 bytes for listener_unique_id) so the maximum size of the array would be ~640k (per stream_output) which is clearly too large for memory contrained devices to support. As is stands, there is no mechanism whereby a Talker can inform a Controller how large of a connected_listeners array it implements. The proposal which was discussed was to allow a lower bound of 0 on the size of the array, and to define a mechanism which a Talker can use to inform a Controller of the size of the connected_listeners array that it implements. What exactly this mechanism would be was not discussed, but two ideas that come to mind are: 1. Use some of the reserved bits in the GET_STREAM_INFO response to convey this information 2. Extend the STREAM_OUTPUT descriptor to include this information The spec should also specify how a Talker device is expected to behave in the situation when the number of connected listeners exceeds the size of the connected_listeners array. The most straightforward thing to do would be to allow a Talker to replace any entry in the array with the parameters associated with the most recent connection. Item 2. How to best support the method Milan is using to shorten connection time by allowing a listener to respond to a CONNECT_RX_COMMAND from a controller immediately, before attempting to establish a connection to the talker. This is working as intended in the constrained environment of professional audio. How do we prevent this from breaking things while at the same time continue to use it for the advantages it provides. Proposal: 2. Allow a Listener that supports FAST CONNECT to respond to a CONNECT_RX_COMMAND message (with the FAST_CONNECT flag bit set) with a CONNECT_RX_RESPONSE message prior to attempting a connection to the Talker specified in the CONNECT_RX_COMMAND message. The motivation is to provide a mechanism whereby a Controller can configure a Listener to connect to a specified Talker without that Talker needing to be on the network at the same time as the Controller and Listener. This could be useful (for example) when configuring a Listener (i.e. a speaker) as a spare that could be swapped in for a failed unit without needing any further configuration. The way the spec is currently written, the Listener doesn't save the Talker's Entity ID into nonvolatile storage until after it successfully establishes a connection to that Talker. The proposal is to allow a Listener to write the Talker's Entity ID into nonvolatile storage immediately after receiving a CONNECT_RX_COMMAND, and to send a CONNECT_RX_RESPONSE message to the Controller with the status set to SUCCESS, and the STREAM_DEST_MAC and STREAM_VLAN_ID fields set to 0. Since a MAC address of all 0's is not a legal MAC address, the controller can know that the connection hasn't been established, but that the parameters have been written to nonvolatile storage. (Thanks Rimas for the summaries.) And a reminder that there is a f2f meeting coming up this month. IEEE 1722.1 Work Group Face To Face Meeting Thursday, May 16, 2019 Genk, Belgium Genk Belgium is where Luminex is located. Exact meeting address for the IEEE 1722.1 meeting soon. Luminex suggested hotels: 1) Ecu Hotel hotelecu.com 2) Alfa Molenvijver hotel mhotel.be 3) Carbon hotel carbonhotel.be If there are people would would like to present who can not make the trip, I will have a web link available so we can video conference. Richard Bugg +1 818-535-5023 richardb@meyersound.com