Stream Wordclock loses Lock

[infiniteimprobability]

which results in a MCLK of 24,576MHz. For 48kHz this is too high. It should be 12,288MHz. (Please correct me if I am wrong)

Hi - since you are using a custom audio interface, I can't answer that question for your code. For I2S as supplied in the ref design, it supports an MCLK:BLCK divider ratio of up to 8:1, so 24576000/8 = 3,072,000 bit clock. Divide by 64 (32b L+ 32b R) and you get 48000 exactly. So an MCLK of 24,576MHz is OK and not too high.

It really sounds like there is a rate mismatch somewhere. Can you either toggle an I/O in your ADAT routine or make an xscope call (https://www.xmos.com/download/public/Tr ... 9923A).pdf) to see in real time what is actually going on?

[voodoosound]

I made a screenshot of the audio output signal in relation to the incoming stream word clock.

The audio output signal is locked, until standard out prints ... lost lock...
I also toggled a pin once per LRCK edge. It was always aligned relative to the preambel.

The port seems to work correctly.

The only thing that seems odd, is the propagation delay of PTP.
I had to increase PTP_NEIGHBOR_PROP_DELAY_THRESH_NS to 1200.
What could be the cause for that?

[voodoosound]

I tried to control the port output ( partout() ) of the biphase coding with a timer too.

Code: Select all

	time += 8;        // 50000000 MHz / 6144000 MHz
	tmr when timerafter(time):> void;

But no difference.
I think the problem must be somewhere in the avb stack.
What prevents the output FIFO from constant filling?

[voodoosound]

I did some digging in the stack.

I was able to track down that manage_buffer() is not called prior to loosing the lock.

Code: Select all

 streaminfo2->valid ==0 

when it should be 1.

I have to do quite some debugging to get a hint, what could go wrong, I think...

I will report back.

[voodoosound]

Hi again...

I made a diagram to clearify the problem.

Debugging this piece of code is very hard, because it is extremly time critical (no printf without messing with the timing) and 3 threads are involved (channel communication). And the 3rd thread depends on incoming Ethernet frames (I cannot match incoming 1722 packets to corresponding samples).

Wireshark shows that the incoming 1722 stream is fine.

Has anyone any suggestion, how to debug this?

[voodoosound]

Hi,

I did some debugging now, and it seems, that somehow control messages in a xc channel are lost.
Attached is a sequence diagram of the process.


I counted the 1722 packets that have been processed, counted its calls to media_output_fifo_maintain(...) and I counted the number of times media_output_fifo_maintain(...) calls notiy_buf_ctl_of_info(...) .
Everything is as intended.

I counted the calls to manage_buffer(...) .
As expected, there are missing calls, when the media clock looses its lock.

The following case from media_clock_server(...) is never met.

Code: Select all

      case (int i=0;i<num_buf_ctl;i++)
        (fifo_init_count == 0) => inuchar_byref(buf_ctl[i], buf_ctl_cmd):

num_buf_ctl and fifo_init_count have always the correct values.
This leads to the assumption, that the function inuchar_byref(buf_ctl, buf_ctl_cmd) does not receive the BUF_CTL_GOT_INFO control token.

But I verified, that notiy_buf_ctl_of_info(...) does its job.


So what is the problem here?
Where do the control messages go?
Is this perhaps related to the thread performance?
I already have set the relevant threads to fast mode, without any difference.