Wrong STREAM_OUTPUT Descriptor

[chris-kuhr]

Hi *,

I am on master branch commit b77cddc.

I have an Openavb talker configured for 96kHz with 2 channels. But avdecccmdline doesn't show the correct values, which prevents any connection.

----------------------- STREAM_OUTPUT -----------------------
descriptor_type: STREAM_OUTPUT
descriptor_index: 0
object_name = Stream Output 0
localized_description = 65535
clock_domain_index = 0
stream_flags = 0x2
	clock_sync_source = 0
	class_a = 1
	class_b = 0
	supports_encrypted = 0
	primary_backup_valid = 0
	primary_backup_valid = 0
	secondary_backup_supported = 0
	secondary_backup_valid = 0
	tertiary_backup_supported = 0
	tertiary_backup_valid = 0
current_format_name = IEC61883-6_AM824_MBLA_96KHZ_8CH
backup_talker_entity_id_0 = 0x0
backup_talker_unique_0 = 0
backup_talker_entity_id_1 = 0x0
backup_talker_unique_1 = 0
backup_talker_entity_id_2 = 0x0
backup_talker_unique_2 = 0
backedup_talker_entity_id = 0x0
backedup_talker_unique = 0
avb_interface_index = 0
buffer_length = 0
number_of_formats = 1
	stream_format_0 = IEC61883-6_AM824_MBLA_96KHZ_8CH

It ought to be 96kHz and 2 channels.

Wireshark shows the correct values sent from the endpoint (FDF SFC: 0x4, Label Multi-Bit Linear Audio Count: 2):

Ethernet II, Src: IntelCor_3f:be:a3 (a0:36:9f:3f:be:a3), Dst: IntelCor_3f:be:a3 (a0:36:9f:3f:be:a3)
IEEE 1722 Protocol
IEEE 1722.1 Protocol
    .... 0001 = Message Type: AEM_RESPONSE (1)
    0000 0... = Status: SUCCESS (0x00)
    .... .000 1001 1100 = Control Data Length: 156
    Target GUID: 0xa0369ffffe3fbea3
    Controller GUID: 0xa0369fffff3fbea3
    Sequence ID: 4
    0... .... = U Flag: False
    .000 0000 0000 0100 = Command Type: READ_DESCRIPTOR (0x0004)
    Configuration: 0
    Descriptor Type: STREAM_OUTPUT (0x0006)
        Descriptor Index: 0x0000
        Object Name: Stream Output 0
        Localized Description: 65535
        Clock Domain ID: 0
        Stream Flags: 0x0002
        Stream Format
            0... .... = Version: 0x0
            .000 0000 = Subtype: 0x00
            1... .... = SF: True
            ..10 0000 = FMT: 0x20
            0000 0... = FDF EVT: 0x00
            .... .100 = FDF SFC: 0x4
            DBS: 0x08
            0... .... = Blocking Flag: False
            .1.. .... = NonBlocking Flag: True
            Label IEC 60958 Count: 0
            Label Multi-Bit Linear Audio Count: 2
            0000 .... = Label Midi Slot Count: 0
            .... 0000 = Label SMPTE Slot Count: 0
----------------------8<---------------------------------------------------------

Any advice?

Best,
Ck

[andrew-elder]

Hi Chris,
I think IEC61883_AM824_MBLA_96KHZ_2CH = 0x00A0040240000200
I don't think this matches your wireshark capture?

[chris-kuhr]

Ok, I found the problem.
avdecccmdline analyzes the dbs value as channel count and seems to ignore the mbla channel count. I set a 2 as dbs value and now it is correct.
I am not sure, but I don't think this is correct behavior. dbs only gives information about the structure of the mbla channel count. at least that is how I understand it. having two channel count fields does not make sense in another way...

[andrew-elder]

1722-2016 has

5.4.3.4 DBS (data block size) field
The 1-octet DBS field has the same definition as IEC 61883-1, which is the size of data blocks in quadlets,
as follows:
 0: 256 quadlets
 1 to 255: 1 to 255 quadlets
For AVTP, the DBS field shall not be set to a value that would cause the AVTPDU length to exceed the
MTU of the network. All AVTPDUs of this format shall contain an integral number of data blocks as
defined in IEC 61883-1.

[chris-kuhr]

Yeah, so I think using the DBS field as channel count is indeed wrong. It is a value that is used to correctly receive AVTP packets, but it should be ignored in connection establishment process. Or am I wrong?

[andrew-elder]

I interpret iec61883-1 Data Block Size to mean the count of the number of quadlets in a data block. And if a data block consists of data from a single sample period, then DBS will change with the number of channels in a packet. I don't know that you are wrong - the specs are not very clear....

[andrew-elder]

@chris-kuhr - are you on the IEEE1772.1 reflector? I guess we could ask for clarification there.

[andrew-elder]

Here is what XMOS do https://github.com/xcore/sc_avb/blob/master/module_avb_1722_1/src/avb_1722_1_aecp_controls.xc#L96

I think the channel count is actually in two places.

[chris-kuhr]

Ok. I will make a pr to avtp pipeline. fixing at least those problems.