acmp_start_fast_connect is also called after the Ethernet cable is un-plugged and then re-plugged.

This causes the stream reconnect to fail after Ethernet cable is re-plugged.

Setup:
Compile with #define AVB_1722_1_FAST_CONNECT_ENABLED 1
Flash the EPs with xflash --boot-partition-size 458752
Connect streams bidirectionally.
Now xrun --xscope the binary on both Endpoints.

Scenario:
EP0 and EP1 boot with fastconnect. Streams are re-connected automatically bidirectionally.
Unplug-replug EP1.
EP1 prints again: Issuing fast connect for 0
Stream EP0->EP1 reconnects and locks
Stream EP1->EP0 does not reconnect.

This can be fixed by making sure that acmp_start_fast_connect is only called once after boot.
E.g. by using a flag:
if(!fast_connect_started) { // Call this only after boot, not after unplug-replug
acmp_start_fast_connect(i_eth);
fast_connect_started = 1;
}

In main.xc of AN00202 (click here) the code comment states we are selecting the 24.576KHz clock. The code doesn't seem to line up with what the xCORE-200 Multichannel Audio board documentation says. I'm not sure which one it's supposed to be as, from what I understand, the PLL used could be factory programmed either way.

// Select 48Khz family clock (24.576Mhz)
mclk_select.output(0);                // <---- ?
pll_select.output(1);

Declarations of c_buf_ctrl are inconsistent in these functions:

void avb_1722_listener(chanend c_mac_rx,
                       chanend? c_buf_ctl,
                       chanend? c_ptp,
                       chanend c_listener_ctl,
                       int num_streams)
{

void avb_1722_listener_handle_packet(chanend c_mac_rx,
                                     chanend c_buf_ctl,
                                     avb_1722_listener_state_t &st,
                                     ptp_time_info_mod64 &?timeInfo)
{

in avb_1722_listener.xc

This causes the problem that if c_buf_ctl is passed null into avb_1722_listener (which is valid because it's declared ?c_buf_ctl), an excepiton is thrown when avb_1722_listener_handle_packet
is called.

Hi,

I purchased an XMOS AVB Endpoint Kit in February 2015. It contained factory firmware version 5.0 (does not support 1722.1 protocol). On building and flashing app_avb_lc_demo in firmware 6.1.1, wireshark logs show that it runs 1722.1 protocol and controller. Since I was working on v5.0 which does not support 1722.1, I was trying to disable 1722.1 protocol in v6.1.1 by setting AVB_ENABLE_1722_1 in avb_conf.h to 0. But, during build, following error was observed -

C:/Users/cchandini/workspace/module_avb/src/avb.xc:573:9: error: unknown function identifier `avb_1722_1_process_packet' (possibly missing prototype?)

On commenting this function call, more build errors were observed -

C:/Users/cchandini/workspace/module_avb_1722_1/src/avb_1722_1_adp.xc: Error: Undefined reference to 'avb_entity_on_new_entity_available'
C:/Users/cchandini/workspace/module_avb_1722_1/src/avb_1722_1_acmp_periodic.xc: Error: Undefined reference to 'avb_listener_on_talker_connect'
C:/Users/cchandini/workspace/module_avb_1722_1/src/avb_1722_1_acmp_periodic.xc: Error: Undefined reference to 'avb_listener_on_talker_disconnect'
C:/Users/cchandini/workspace/module_avb_1722_1/src/avb_1722_1_acmp_periodic.xc: Error: Undefined reference to 'avb_talker_on_listener_connect'
C:/Users/cchandini/workspace/module_avb_1722_1/src/avb_1722_1_acmp_periodic.xc: Error: Undefined reference to 'avb_talker_on_listener_connect_failed'
C:/Users/cchandini/workspace/module_avb_1722_1/src/avb_1722_1_acmp_periodic.xc: Error: Undefined reference to 'avb_talker_on_listener_disconnect'
C:/Users/cchandini/workspace/module_avb_1722_maap/src/avb_1722_maap.xc: Error: Undefined reference to 'avb_talker_on_source_address_reserved'

Is there any clean and easy way to disable 1722.1 protocol in v6.1.1 ?
Also, is v5.0 firmware available for download anywhere? Help required asap.

Thanks!

There are 8 references to stream_mutlicast_filter in avb.xc. Try as I might, I can't find the word mutlicast in the dictionary... 😉

Should be stream_multicast_filter.

AVB_NUM_SINKS and AVB_NUM_SOURCES may be zero for talker-only or listener-only devices. However, avb_1722_1_aecp.c contains "XXX/AVB_NUM_SINKS" without checking.

Customer testing with frequent grandmaster transitions revealed a scenario, where media clock generation gets stuck in its "debouncing period" if there is a PTP discontinuity before media clock lock is reached.

Timestamp-uncertain with some rudimentary handling would probably avoid this scenario.

The lib_tsn/src/utils/random.xc & .h are copies in from lib_crypto. They need to be removed, otherwise trying to build against any other module that includes random.xc causes 'Multiple definition' errors.

Observed a Talker Advertise JoinMt that had priority set to 0, which can cause SRP failure code 13 on switch (Requested priority is not an SR Class priority)

Andy Lucas removed GET_AVB_INFO response support back in 2013 (see here). No real comment from the author on this particular change. Commit comment only says

Enabled Talker on the DC endpoint and fixing Talker attributes

I wasn't under the impression that GET_AVB_INFO was Talker specific.

This change has propagated all the way into current 2017 code, over in the XMOS repos (see here). Since it reports very important status info, like asCapable, would it be worth re-integrating this command response?

When AN00202/3 is configured to 8 streams (1 channel each), media clock lock fails on last 1 or 2 connected streams

Enabled by setting:

#define AVB_NUM_SOURCES 8
#define AVB_NUM_SINKS 8
#define MAX_AVB_STREAMS_PER_LISTENER 8

In testing some switch restart scenarios, talker can permanently lose its Listener Ready attribute structure, making it unable to re-establish streaming audio to a remote listener

1. This documentation block (shown below) is inconstant with the actual function.
2. Why are all functions/tasks defined in .c or .xc except for this one which is in .h? Please be consistent.
3. There is a static inline unsigned int declaration of this function in the corresponding .c file, with no implementation defined. I've removed it in my own code without any issues. Why is it there?

/**
 *  \brief Used by the audio output system to pull the next sample from the FIFO
 *
 *  If there are no samples in the buffer, a zero will be returned. The current
 *  ref clock time is passed into the function, and the FIFO will record this
 *  time if the sample which has been removed was the marked sample
 *
 *  \param s the FIFO to remove a sample from
 *  \param timestamp the ref clock time of the sample playout
 */
 /*
unsigned int
audio_output_fifo_pull_sample(buffer_handle_t s,
                                  unsigned int timestamp);
*/
__attribute__((always_inline))
unsafe static inline unsigned int
audio_output_fifo_pull_sample(buffer_handle_t s0,
                              unsigned index,
                              unsigned int timestamp)

Applies to:

• /src/audio_buffering/audio_output_fifo.h
• /src/audio_buffering/audio_output_fifo.c

Internal bug 14004

In MDSyncReceiveSM, a DISCARD due to folllowUpReceiptTimeoutTime means PortSyncSyncReceive should not get a rcvdMDSync event.

However in XMOS code, even if a folllowUpReceiptTimeout event occurs, syncReceiptTimeoutTimeInterval is updated, which is incorrect and breaks the correct operation of the AGED event in PortAnnounceInformation.

• IEEE Std. 802.1AS-2011 Figure 10-2
• IEEE Std. 802.1AS-2011 Figure 10-4
• IEEE Std. 802.1AS-2011 Figure 11-6

If PLL_OUTPUT_TIMING_CHECK is set to 1 then lib_tsn fails to compile:

lib_tsn/lib_tsn/src/media_clock/media_clock_server.xc:387:15: error: use of undeclared identifer `x'
if (x==3)

It is not clear exactly how, but after a period of switching grandmaster between two nodes, pDelay on a third node becomes invalid. It is certain, however that drift between local and grandmaster clocks causes pDelay to drift too and potentially become invalid.

Invalid pDelay is observed in update_path_delay. The value is initially negative, and then, after adding a correction to clamp invalid negative to valid zero, the value becomes too large, crossing the 800ns threshold.

Both negative and too large values correctly cause reset of asCapable. Specification is written such that we assume invalid value is caused by peer and wait for peer to "correct itself". We continue computing pDelay until it becomes valid again and set asCapable back.

To recover asCapable in this manner, neighborRateRatio needs to be implemented, correcting for drift of local and grandmaster clocks.

Without neighborRateRatio, we seem to get stuck with asCapable unset, discarding sync messages so not doing any PTP adjusting that would bring asCapable back.

The setup to demonstrate the issue is 2 endpoints and a switch (Extreme Networks, but MOTU or DSP4YOU should work too). Unmodified firmware, changing PTP priority on the switch at random intervals between 0 and 30 seconds. Time to failure only a few minutes. With negative pDelay clamping implemented as described above, allow a couple of hours.

Currently both talker and listener sides of a connected stream try to convert Talker Failed to Advertise once their network ports have gone of out SRP boundary. This code generates a MAD Join of the Advertise attribute. This is fine on talker, but on listener it effectively creates a second talker of the same stream, because that listener will begin declaring identical Talker Advertise.

I have seen X440 switch rightly get confused by seeing two talkers for the same stream.