xCORE-200 MC Audio Board AVB connection problem with MOTU

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
Post Reply
User avatar
arvid
New User
Posts: 3
Joined: Thu Jul 23, 2015 9:15 pm

xCORE-200 MC Audio Board AVB connection problem with MOTU

Post by arvid »

Hi,

We just got our xCORE-200 Multichannel Audio Platform dev board in! Ran fine with the pre-flashed USB audio interface project.

We're targeting an AVB device, so I've been testing the AN00203 gigabit AVB with TDM demo code without any modifications.

I've testing with a MOTU Ultralite AVB audio interface, which has AVB control software (a web app running from the MOTU device). The xCORE shows up in it's device list and it allows me to specify AVB stream connections from the MOTU to the xCORE's inputs, as well as connect AVB streams from the xCORE into the MOTU. That works as expected.

But, I have found an issue:

When connected to a MOTU Ultralite AVB via an ethernet cable, the audio being sent from the xCORE drops out for a second or two every 30 sec or so. When this happens the xCORE board also disappears temporarily from the list of devices in the MOTU AVB control webapp. After a few seconds the audio comes back on and the board shows up again in the MOTU app. Audio being sent the other direction (from the MOTU to the xCORE via AVB) does not seem to drop out, or if it does, only for a brief instant before everything comes back to normal.

There is no other AVB device in this setup. All devices are set up at 48KHz sample rate. The dropouts continue when the MOTU's control app is not open on any computer.

When I try to connect the xCORE dev board to a macbook pro 8,2 running OS X 10.10, it shows up as an audio interface and there are no dropouts with audio sent in either direction - all is well.

Setting the xCORE's clock source to that of the MOTU does not help. Audio Dropouts happen more frequently if I set the clock source of the MOTU to that of the xCORE, but control dropouts happen at the same rate as before.

Any thoughts on this problem? Perhaps it is a clocking issue? A higher level 1722 communication issue? Or maybe MOTU is not implementing the spec properly? We're trying to debug what might be happening, but not sure where to start.

Thanks,
Arvid


User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Hi,
it's difficult to say what;s going on without some debug info. A whole load of reasons exist for streaming to stop touching almost every part of the stack. The two main tools for getting some debug visibility are:

xrun with the --xscope switch (or using the GUI with Target I/O via xSCOPE in run configurations dialogue)
i.e. Running from the host with debug output on and messages printed to the console. This will give you all sorts of useful information about events including PTP status, 1722.1 control, SRP connection and media FIFO (ie. clock recovery). Analysing this log will provide a whole insight into what's going on at the stack level.

Wireshark
This can really help and you will be able to see 1722.1 control messages etc. However, to get the full story, you may need ethernet tap hardware. The reason for this is inherent to the way AVB works - it uses a multicast MAC address and the switch will not route this multicast to ports that are not subscribed to the stream. However in your case, it doesn't sound like you have a switch, so an ethernet tap is the best way forward for a couple of reasons.

The fact that the OSX endpoint/controller works OK but MOTU not does point the finger somewhat in MOTU's direction.. However, again more debug info is need to go forward. Obviously ensure you are using their latest firmware and open a support query with them too.
User avatar
arvid
New User
Posts: 3
Joined: Thu Jul 23, 2015 9:15 pm

Post by arvid »

Thanks for the info. Have been running via XScope to get the debug_printfs in the XTime console and I've got a little more information. It appears that the xCORE board is switching its gPTP clocking role continuously aboput once per second between master and slave, sometimes rated as asCapable, sometimes not. Perhaps this is why the MOTU device is disconnecting from it? This type of clock toggling does not happen when connected to the mac.

I'm not sure why it's doing this, but the relevant code appears to be located in ptp_periodic() in lib_tsn. Perhaps some sort of timeout error is happening – a Sync, Pdelay or Announce timeout? These are described in 3.2.3.5. Error Conditions of AVnu's AVB Software Interfaces and Endpoint Architecture Guidelines

The console will look something like this:

Code: Select all

RX Announce, Port 0
Average pdelay of 318 ns
PTP Port 0 Role: Master
asCapable = 0
Average pdelay of 0 ns
Average pdelay of 15 ns
PTP Port 0 Role: Master
asCapable = 1
TX Announce, Port 0
RX Announce, Port 0
NEW BEST: 0
PTP Port 0 Role: Slave
my_addr_lo: 13038, my_addr_hi: 13042, conflict_lo: 53571, conflict_hi: 53576
PTP sync locked
Average pdelay of 15 ns
PTP Port 0 Role: Master
asCapable = 0
Average pdelay of 5 ns
Average pdelay of 5 ns
PTP Port 0 Role: Master
asCapable = 1
RX Announce, Port 0
NEW BEST: 0
PTP Port 0 Role: Slave
DISCONNECTING Talker stream #0 (2297808270000) -> Listener 0:1:F2:FF:FE:0:21:5E
Talker stream #0 off
MSRP: Deregister stream request 229780:8270000
Talker MAD_Leave
Listener MAD_Leave
Decreasing port 0 shaper bandwidth to 0 bps
…
The it will reconnect and continue with something like

Code: Select all

Average pdelay of 8 ns
RX Announce, Port 0
PTP sync locked
CONNECTING Talker stream #0 (2297808270000) -> Listener 0:1:F2:FF:FE:0:21:5E
MSRP: Register stream request 229780:8270000
Added stream:
 ID: 2297808270000
 DA:91:E0:F0:0:32:EE:
 max size: 224
 interval: 1
MVRP: Joined VID 2
Talker stream #0 ready
Increasing port 0 shaper bandwidth to 17024000 bps
Talker stream #0 on
Average pdelay of 17 ns
RX Announce, Port 0
Average pdelay of 17 ns
PTP Port 0 Role: Master
asCapable = 0
Average pdelay of 0 ns
Average pdelay of 20 ns
PTP Port 0 Role: Master
asCapable = 1
TX Announce, Port 0
RX Announce, Port 0
NEW BEST: 0
PTP Port 0 Role: Slave
Average pdelay of 12 ns
RX Announce, Port 0
PTP sync locked
Average pdelay of 12 ns
RX Announce, Port 0
…
The issue remains even if the talker stream is disabled in avb_conf.h with

Code: Select all

#define AVB_1722_1_TALKER_ENABLED 0
or when gptp_media_clock_server() is set to PTP_SLAVE_ONLY in main.xc

I haven't tried using wireshark to diagnose yet, but maybe that's a next step to figure out why this is happening?

Any further direction in figuring this out would be greatly appreciated. Thanks!
Post Reply