Issues with AN00202 on xCORE-200 MC Audio board

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
Post Reply
ahogen
Member++
Posts: 26
Joined: Fri Mar 31, 2017 5:16 pm

Issues with AN00202 on xCORE-200 MC Audio board

Post by ahogen »

Howdy!

I downloaded and imported version 1.0.3 of AN00202_gige_avb_i2s_demo into a blank workspace. Hit build and xTIMEcomposer pulled in all the latest dependencies from the xmos website (hidden in the "off topic" section below).

Library/dependency versions
  • lib_ethernet [3.3.0]
  • lib_gpio [1.1.0]
  • lib_i2c [3.1.6]
  • lib_i2s [2.3.0]
  • lib_locks [2.0.3]
  • lib_logging [2.1.0]
  • lib_otpinfo [2.0.1]
  • lib_tsn [7.0.3]
  • lib_xassert [3.0.0]
Setup
I have a pair of AudioScience Hono 4.4M endpoints/interfaces and have been using their ASIControl software as the AVB/TSN controller to create talker-listener links between devices. Everybody is configured to have 8 channels per stream.

I have a signal generator on one of the AS Hono devices (we'll call it device 'A') and have successfully sent that signal to the second AS Hono device (call it 'B'). I have also put a signal on the XMOS xCORE-200 MC board and set it to send it's signal out to either A or B successfully.
A -----> B          ok
MC ----> A or B     ok
Problem

When I set A to transmit to the XMOS MC board (again using the ASIControl software) the MC board does seem to respond to the command, but I don't get any audio out of the DAC. I have scoped all of the pins on the J7 header thinking it was just a DAC configuration issue, but all the data lines are silent at 0V. Probing pin 3 of the physical XMOS IC also shows a constant voltage.

Summary:
  • A talks to B. B listens successfully.
  • MC talks to B. B listens successfully.
  • A talks to B and MC. B listens successfully. MC doesn't output audio to DAC.
A -----> B          ok
MC ----> A or B     ok
A -----> MC         NO SIG OUT

What should I be looking for? xSCOPE is already integrated into this project. How could I, maybe, print out audio samples directly after they are parsed from an incoming packet?

Any help would be appreciated. As you can probably tell, I'm still a n00b with AVB/TSN.

Thanks!


ahogen
Member++
Posts: 26
Joined: Fri Mar 31, 2017 5:16 pm

Post by ahogen »

Additionally, here is something that happens occasionally. It will continue until I manually halt execution, so it never resolves itself. If I re-run the code (no rebuild necessary) I can run without encountering this error.

I found this message in printed from lib_tsn/src/media_clock/media_clock_server.xc around line 203, but I have no idea what this actually means in terms of the listening stream. Did it lose sync with its timing resource? Are samples being thrown away? What causes this in the first place?
PTP Port 0 Role: Master
Setting clock source: INPUT_STREAM_DERIVED
PTP Port 0 Role: Master
Joined SRP domain (VID 2, port 0)
PTP Port 0 Role: Master
MAAP reserved Talker stream #0 address: 91:E0:F0:0:E0:FD
PTP Port 0 Role: Master
CONNECTING Listener sink #0 -> Talker stream 1CF70064600C1, DA: 91:E0:F0:0:C6:CC
Listener sink #0 chan map:
  0 -> 0
  1 -> 1
  2 -> 2
  3 -> 3
  4 -> 4
  5 -> 5
  6 -> 6
  7 -> 7
MSRP: Register attach request 1CF700:64600C1
Added stream:
 ID: 1CF70064600C1
MVRP: Joined VID 2
Added stream:
 ID: 1CF70064600C1
 DA:91:E0:F0:0:C6:CC:
 max size: 224
 interval: 1
Media output 0 compensation too large: -1106 samples
// .....
Media output 1 compensation too large: -1107 samples
// .....
Media output 3 compensation too large: -1108 samples
// .....
Media output 0 compensation too large: -1109 samples
Media output 1 compensation too large: -1109 samples
Media output 2 compensation too large: -1108 samples
Media output 3 compensation too large: -1109 samples
Media output 4 compensation too large: -1109 samples
Media output 5 compensation too large: -1109 samples
Media output 6 compensation too large: -1108 samples
Media output 7 compensation too large: -1109 samples

// .... and so on.....
Ideas?
Attachments
an00202 listener stuck.txt
Full output from xTIMEcomposer terminal during this lockup.
(85.03 KiB) Downloaded 294 times
an00202 listener stuck.txt
Full output from xTIMEcomposer terminal during this lockup.
(85.03 KiB) Downloaded 294 times
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Hi. I fixed a compensation too large error by adding the following code to avb_conf.h

Code: Select all

#define AUDIO_OUTPUT_FIFO_WORD_SIZE 256
Maybe with such a large compensation value your situation wants, 256 wouldn't work. But you might try increasing the value to see if you can find a value that actually works for you. For me I found the maximum size I could use is something between 512 and 896 (didn't find an exact value).
ahogen
Member++
Posts: 26
Joined: Fri Mar 31, 2017 5:16 pm

Post by ahogen »

Thanks for the reply.

I tried that out as you suggested, but it didn't seem to change anything.

Could it be that XMOS as a Listener is having trouble syncing to the Audio Science clock? This might explain why I didn't have any issues when the XMOS board was a Talker.

I tried to make the XMOS unlock a locked clock if there is a large diff change by changing the following define to 1

Code: Select all

// lib_tsn/src/media_clock/media_clock_server.xc
#define UNLOCK_ON_LARGE_DIFF_CHANGE 1
... but that didn't appear to change anything either. I'm having a hard time figuring out what to try since functions and variables rarely have any associated commentary in the code. I'm new to AVB/TSN and XMOS so the un-commented code isn't always intuitive to me. And it's not like a message saying "Media output x compensation too large: " helps me to figure out what is wrong or what I need to change.

Thanks again, akp. I'm going to keep looking. If anyone has any ideas, please let me know.
ahogen
Member++
Posts: 26
Joined: Fri Mar 31, 2017 5:16 pm

Post by ahogen »

Putting the media clocking issues aside, I have now at least determined that I am getting data, but nothing is being retrieved from the output fifo and sent to the DAC.

I put two xscope probes in the audio buffering code, as shown below (existing function code omitted).

Code: Select all

/**********************************************************
* lib_tsn/src/audio_buffering/audio_output_fifo.h
**********************************************************/
__attribute__((always_inline))
unsafe static inline unsigned int
audio_output_fifo_pull_sample( ..... )
{
	// ......
	
	xscope_int(FIFO_OUT_PULL_SAMP, sample);
	
	return sample;
}

Code: Select all

/**********************************************************
* lib_tsn/src/audio_buffering/audio_output_fifo.c
**********************************************************/
void
audio_output_fifo_strided_push(buffer_handle_t s0,
                               unsigned index,
                               unsigned int *sample_ptr,
                               int stride,
                               int n)

{
	// ......

    if (new_wrptr != s->dptr) {
        *wrptr = sample;
        wrptr = new_wrptr;
        xscope_int(FIFO_OUT_PUSH_SAMP, sample);
    }

	// .....
}
And with those probes in place, I can see that my sine wave test signal is making it to the XMOS board and put into the "sample" variable. It is not, however, being pulled from the FIFO at all.

Hmm....
ahogen
Member++
Posts: 26
Joined: Fri Mar 31, 2017 5:16 pm

Post by ahogen »

I was able to show that the Listener (the XMOS MC Audio board) is able to pull TSN packets from the multicast stream and parse them into samples by inserting another xSCOPE probe into "audio_output_fifo_strided_push(...)" which lives in "audio_output_fifo.c" (not .h). The test signal showed up on the xSCOPE in real-time. The issue then was trying to get the data out of the FIFO.

At the end of the day yesterday I determined that the "zero_flag" element (in an "ofifo_t" type struct) was never getting cleared, so when a sample is pulled from the output FIFO, it is set to zero before being returned to the calling function. By commenting out

Code: Select all

if (s->zero_flag)
    sample= 0;

from "unsafe static inline unsigned int audio_output_fifo_pull_sample(...)" in the file "lib_tsn/src/audio_buffering /audio_output_fifo.h", sample data is successfully pulled from the FIFO and passed along down the line and ends up at the output (channel 0) of the DAC.

If a message like "Media output 0 compensation too large: -1109 samples" is being printed, the audio stream out of the XMOS board will become choppy. Commenting out the "debug_printf()" line in "lib_tsn/src/media_clock/media_clock_server.xc" will remove this choppiness. Obviously this error message shouldn't just be ignored, but it is useful to show a constant output from the xCore-200 MC board.

Going to try and trace this "zero_flag" back up the line and figure out why the responsible parties weren't properly clearing it.
Post Reply