Using AVB library at speed != 48kHz

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
User avatar
akp
XCore Addict
Posts: 209
Joined: Thu Nov 26, 2015 11:47 pm

Re: Using AVB library at speed != 48kHz

Postby akp » Fri Jul 13, 2018 1:42 pm

I didn't have to reorder the talker channel map I don't think. I pretty much have the FSYNC set up with a -1 offset like in I2S, I don't use MSB framing. But it shouldn't really matter.
azs
Member
Posts: 14
Joined: Mon Oct 09, 2017 11:11 am

Postby azs » Fri Jul 13, 2018 2:09 pm

Okay thanks !
Dig...dig...dig !
azs
Member
Posts: 14
Joined: Mon Oct 09, 2017 11:11 am

Postby azs » Mon Jul 16, 2018 10:43 am

Well, it seem's that I have a 1-BCLK shift on my samples but.... not all the times ! I can have ~5 to ~30 samples that are corrects, then the next one is shifted by one BCLK, making an audio error ! This is random, absolutely not cyclic.
Is it a "real-time" issue on the TDM interface ? Maybe does it wait for an other interface for some data that arrives too late ?

"Where" to look for this issue in the code ? :-s

PS : I tried the "set_core_high_priority_on()" on the tdm_master core, and also stops all other un-necessary interfaces, but not better.....
azs
Member
Posts: 14
Joined: Mon Oct 09, 2017 11:11 am

Postby azs » Mon Jul 16, 2018 1:58 pm

Correction : this is not a clock shift of 1-bit, this is the MSbit that is missing (i.e. the LSBit still ends at the correct position, this is not shifted).
Test method : I send a -144dBFs signal, i.e. there is only 3 values that are output : 0x000000, 0x000001, 0xFFFFFF (i.e. 0, +1 and -1 respectively).
Sometimes (scope on the TDM bus with persistance infinite), I can read the value 0x7FFFFF, meaning that the MSBit of 0xFFFFFF was corrupted. This lead to the maximum value in positiv phase, instead of "-1".
User avatar
akp
XCore Addict
Posts: 209
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Mon Jul 16, 2018 2:02 pm

is this output from the XMOS to your FPGA or vice versa?
azs
Member
Posts: 14
Joined: Mon Oct 09, 2017 11:11 am

Postby azs » Mon Jul 16, 2018 2:06 pm

Output from the XMOS (XMOS TDM out) that is scoped
User avatar
akp
XCore Addict
Posts: 209
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Mon Jul 16, 2018 2:14 pm

Sorry can't help you there as I don't do output from the XMOS at present.
azs
Member
Posts: 14
Joined: Mon Oct 09, 2017 11:11 am

Postby azs » Tue Jul 17, 2018 10:03 am

Thanks akp. But debug continues an have some news. Here is my audio flow :

ASIO Sender -> FPGA device 1 --(TDM1)--> XMOS device 1 --------------------> AVB Network --------------------> XMOS device 2 --(TDM2)--> FPGA device 2 -> ASIO receiver

I send a -144dBFS on ASIO sender to see the -1 / 0 / +1 values (see post above).
When probing the TDM 1, everything was good, i.e. FPGA do the job as expected.
When probing TDM 2, I can see b23 of my audio word that is sometimes corrupted. That's why I was focusing on the TDM output.

But I tried something else : instead of sending audio from ASIO, I modified XMOS device 1 firmware to not use its TDM input as audio source, but directly use static value of 0xFFFFFF00 to send to AVB buffer.
Then still scope-out the TDM2. Now, I cannot see any TDM bit error !
This mean that my issue is not on TDM out part, but TDM in ! (I will try with others static values like 0x5555... and 0xAAA..... to be sure)

Conclusion : FPGA does output correct TDM words, but XMOS seems to miss some bits when sampling in ! So maybe simply a timing issue ?
azs
Member
Posts: 14
Joined: Mon Oct 09, 2017 11:11 am

Postby azs » Tue Jul 17, 2018 11:29 am

Well, alright ! Now my AVB system is working @ 96kHz.
I changed the FPGA TDM data out clock edge, to "win" half period time, then add 8ns delay on XMOS TDM input pins with set_pad_delay() in order to have a good setup and hold time (estimated with scope on TDM bus).
Now I have good audio signal !

So it was just poor timing that was not highlighted @ 48k but critical @ 96k.

Thanks akp for your support.

Now still remains the "how to" change sample rate at runtime, but at least now I have a functional solution, this is a good starting point.

Happy, I am ;-)
User avatar
akp
XCore Addict
Posts: 209
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Tue Jul 17, 2018 12:56 pm

Glad to hear of your success! IO timing was for sure my first thought and the place it makes most sense is master TDM in rather than master TDM out since that is the interface most likely to show timing errors. Good luck!

Who is online

Users browsing this forum: No registered users and 21 guests