SliceKit AVB Daisy Chain Problem

[zachwilliams]

Hey everyone,

I bought 2 SliceKits along with the pieces necessary for the AVB demo (an audio slice and 2 ethernet slices per SliceKit) and loaded up the newest AVB Daisy Chain code as outlined here: https://github.com/xcore/sw_avb_dc/blob ... kstart.rst

The problem is, when I connect one of the SliceKits to my MacBook via Thunderbolt Ethernet adapter and go to Audio MIDI Setup -> Show Network Device Browser, the SliceKit shows up as an AVB device but but says 0 in/0 out instead of 4 in/4 out. I've attached a screen shot.

Anyone else have this issue?

I'm running Yosemite (10.10).

Also - with this AVB Daisy Chain demo, should I be able to input audio from 1 audio slice and plug in headphones and hear the output in the audio slice from the second SliceKit?

[infiniteimprobability]

Anyone else have this issue?

Hi - yes I have been able to recreate this. Channel count reported correctly on maveriks but gets zeroed on yosemite.

The entity model of the endpoint hasn't changed so it looks like the way AVDECC is done in OSX has changed between versions.

Interestingly, the LC (single eth port version) is still correctly enumerated in yosemite so that will definitely be a clue as to what has changed.

This has now been reported as a bug internally within XMOS. Of course it's possible this is an OSX bug in the controller, rather than a bad descriptor.. This will obviously take some time and resource to track down and analyse.

Could I ask that you submit a bug to help raise the priority? https://www.xmos.com/rt3/SelfService/Create.html

Also - with this AVB Daisy Chain demo, should I be able to input audio from 1 audio slice and plug in headphones and hear the output in the audio slice from the second SliceKit?

Yes, but you'll need to change the config so that there is a 1722.1 controller embedded within the endpoint to connect the streams. More info here:

http://www.xcore.com/questions/2961/xmos-avb-lc-demo

[zachwilliams]

Thanks infiniteimprobability.

That helps to know I'm not the only one having that issue on Yosemite.

Just submitted a bug using the link you provided.

The link to setup the embedded controller is helpful - thanks. I am still having issues though... crossing my fingers that I was doing everything correctly, but maybe I missed something.

I tried flashing the one slicekit with the default code from the 1.0.6rc0 release and then tried running the other slicekit with

Code: Select all

#define AVB_1722_1_CONTROLLER_ENABLED 1

- also note that I rebuilt the code after changing the value to "1" for enabling the controller.

The slicekit with controller enabled would be the talker, correct?

I tried plugging in my output from my laptop to the slicekit talker (jack 1-2 in) and plugged in headphones to the listener slicekit (jack 1-2 out) and didn't hear anything. Is there anything else I'm missing?

[infiniteimprobability]

The slicekit with controller enabled would be the talker, correct?

Yes - the talker then connects to the advertised listener sink using the code in main.xc:

Code: Select all

if ((entity->vendor_id == XMOS_VENDOR_ID) &&
       ((entity->listener_capabilities & AVB_1722_1_ADP_LISTENER_CAPABILITIES_AUDIO_SINK) == AVB_1722_1_ADP_LISTENER_CAPABILITIES_AUDIO_SINK) &&
       (entity->listener_stream_sinks >= 1))
    {
      // Ensure that the listener knows our GUID
      avb_1722_1_adp_announce();

      avb_1722_1_controller_connect(my_guid, entity->guid, 0, 0, c_tx);

I tried plugging in my output from my laptop to the slicekit talker (jack 1-2 in) and plugged in headphones to the listener slicekit (jack 1-2 out) and didn't hear anything. Is there anything else I'm missing?

It worked for me - however I wasn't able to get the controller on the other side to connect in to the local listener (i.e. stream in both directions), even with..

Code: Select all

#define AVB_1722_1_MAX_ENTITIES 2

So there is something to investigate here.

[infiniteimprobability]

The cause of the OSX enumeration problem has been found. It was an XMOS descriptor issue, but was not immediately obvious because it was part of the descriptors that are generated at runtime (memory optimisation) such as AEM_AUDIO_CLUSTER_TYPE, AEM_STREAM_INPUT_TYPE, AEM_STREAM_PORT_INPUT_TYPE, AEM_STREAM_OUTPUT_TYPE and AEM_STREAM_PORT_OUTPUT_TYPE. See code guarded with AEM_GENERATE_DESCRIPTORS_ON_FLY. So these had to be captured via wireshark at enumeration.

The issue was regarding indexing of the clusters (channels) within the stream. Both input/outputs were mapped to the same index, causing a descriptor error which OSX handles silently by zeroing out the channel count. Clearly OSX maveriks wasn't so stringent in checking.

The fix is quite easy. There are 3 lines of code in avb_1722_1_aecp.c that need patching:

- hton_16(stream_port->base_cluster, read_id * AVB_NUM_SOURCES);
- hton_16(stream_port->base_map, read_id);
+ hton_16(stream_port->base_cluster, AVB_NUM_MEDIA_OUTPUTS + (read_id * AVB_NUM_SOURCES));
+ hton_16(stream_port->base_map, AVB_NUM_SOURCES + read_id);

- hton_16(audio_map->mappings.mapping_stream_index, read_id);
+ hton_16(audio_map->mappings.mapping_stream_index, read_id % AVB_NUM_SINKS);

This corrects the mapping and clusters indices so that the sinks (Stream port input) go first, followed by the sources.

I have tested this and it works. This fix is logged / tracked and will be applied at a future release. Thanks for reporting the issue.

[akp]

Sorry to revive an old topic. Just wanted to thank infiniteimprobability for posting the fix for this issue. I just updated from Mavericks to El Capitan and was worried my setup was ruined.

Having said that, I just downloaded the 1.0.6rc code for the Daisy Chain kit a few weeks ago and the issue wasn't resolved there... should I attempt to merge in the latest AVB/TSN lib for my build? Obvs for the 1.0.6rc release I am using 13.2.3 tools but if I could move to 14 tools (which I also use for other projects) that would be desirable.