Using AVB library at speed != 48kHz

[azs]

Hi there !

We are working on an AVB design with an xCORE-200, and would like to run audio at speeds others than 48kHz that is the default library speed setting (AN00203_gige_avb_tdm_demo).
I know this is possible (regarding some enums in the code). I have identified some functions that are audio clock related, because they take a sample_rate as an argument :

- set_device_media_clock_rate()
- set_source_format()
- set_sink_format()

But with no how-to manual, I have many questions :
- is there others functions that need to be called to change sample rate ?
- is it possible to change sample rate "on the fly" ? (during runtime) Or should the AVB/TDM/others... tasks be reset in any way ?
- we are using a TDM interface. This interface is thus master and provides LRCK and BCLK to our FPGA. The only thing we provide is the MCLK for the design (256xFs). When switching from 48k to 96k, should we double-speed the MCLK ?
- at 96k, will the TDM bus LRCK be 96k ? or will it still be 48k but with 2 samples used for each channels (2 x 96k samples), dividing by 2 the max number of possible channels

For now with the early tests we have made, when doubling the MCLK coming from our FPGA, the XMOS immediatley goes into kind of hard fault..... So I guess changing sample rate is not something really obvious.... so are my questions above !

Thanks for any help.
Cheers,

[azs]

Nobody never tried to run the Gibabyte AVB stack at a sample rate other than 48kHz ?????

Thanks !

[akp]

Hi. I've run the AVB stack in TDM at 96k and 192k. Will take some mods but works. I have posted up some bugs I found and fixed so take a look on the forums, you can search my posts. I have only run the code with a single fixed sample rate, not changing on the fly. i.e. I have a build that works at 192k but no other rate, likewise one for 96k and one for 48k. I also don't run input stream defined, but local clock; got a slow FSYNC in input stream defined at 192k when testing with the MacBook. I only use inputs, no outputs.

You will want to do a lot of testing to explore the limits of the design. But basically I have found I got the following to work:
192k x 4 ch/lane x 2 TDM lanes (8ch total)
96k x 8ch/lane x 2 lanes
96k x 4ch/lane x 4 lanes

I think you are referring to BCLK and not MCLK. I am pretty sure the TDM won't work with BCLK > 25MHz. The TDM protocol expects 32 bits/sample and FSYNC at the sample rate. I.e. if you use 96k x 8ch/lane the BCLK will be 96k x 8 x 32 = 24.576MHz which is OK. The FSYNC (aka LRCLK but that is really I2S not TDM) will be 96kHz. I always use a 50/50 FSYNC so for 96 x 8 it would be high for 128 BCLKS and low for 128 BCLKs.

Hope this helps.

[azs]

Thanks akp for your answer, feel less lonely now :)
I will have a look to your posts.
You say "will take some mods".. that's the mode I'm interested in :)

We can accept not changing on the fly as a begining. Meanwhile, have changed some #define and some constants and AEM descriptors to have a card working at 96k (and only this frequency).
Saw that BCLK is still 256*Fs, i.e. 24.576MHz this time. The XMOS seems to be happy with my FPGA clock, design is running... but when I take out TDM data and displays it in an ASIO scope, this is an horror show ! Sin wave is with a DC offset (never goes below zero), each sin top and bottom curve is inverted, artefact are visible along the trace.... in other words, some sign bit issues, sample ordering issues, etc.....

So obviously yes, there is some mods to do !! (I only use 2 TDM lines with 8ch per line)
Will start by looking for your other posts.

Thanks ! And any additionnel help / advices / code mods will be highly appreciated ;)
Cheers,

[akp]

You may have to fine tune the timings for the ADC output -- this will be for your specific hardware. I did it by a combination of bit shifts on the RX (i.e. shift left in case the RTT is more than one bit clock) and calling set_pad_delay() on the various TDM input pins.

I think all my code changes might be a bit too specific for my situation. But one big tip I have for you is if you use 192k for sure you will need to replace the double buffer in the talker frame buffering with a FIFO because there is a race condition in avb_1722_talker_send_packets that leads to dropped packets. I used an 8 level FIFO. I have an outstanding pull request on another bug in that function causing out-of-order samples. I need to generate a new pull on the git but it's a few files that have to change if you do the FIFO.

[azs]

TDM bus is directly connect to a FPGA. TDM IF inside FPGA is written by ourselves, and wrote it to be well aligned to the good clock edge (XMOS drives-out on falling edge, my FPGA samples-in on rising edge, and reversely, I drive out on falling for the XMOS to have a good setup and hold on rising edge). Do you think that working at 96k can change XMOS clock-to-data edges being shifted so much to have issues, when 48k is okay ? Answer to myself : let's take out the scope to check ! ;-)

I've looked over your posts in the forum, found some interesting things, but no direct explanations of your mods..... but highly possible I've missed some posts, as I focused only on the topic title.

Sorry to ask for so much information, but I'm basically a hardware guy (being, with time, more software aware lol), and moreover the first time working with XMOS. So problems specific to this chip architecture are brand new for us, we have no background, and moreover, AVB stack is just a huge machine that is completely beyond us !

[akp]

I have big propagation delays in my system, you probably don't in yours. Yes you have to scope it. Also there is a great design note on computing the setup and hold time you will want to read -- XM010258A
I don't know if there is such a thing as a hardware guy who couldn't benefit from becoming more software aware.

I think you probably got most of the mods in the descriptors, I based the settings off the I2S demo which I suspect you did, too. I also changed my code so I can generate talker only configs which is what I need but sounds like you don't use. In that case I needed to disable the input stream derived clock and force local clock only. Also like I said I think you need to be careful so the BCLK <= 25MHz; that will limit the slot count at 192k to 4 slots/lane I am pretty sure.

[azs]

Thanks akp for design note, I will have a look to this !
Regarding clock, I'm running at 24.576MHz so this is good on this side.

Just to know, have you changed something in the channel mapping when in 96k ?

Code: Select all

for (int j=0; j < AVB_NUM_SOURCES; j++)
  {
    const int channels_per_stream = AVB_MAX_CHANNELS_PER_LISTENER_STREAM;
    int map[AVB_MAX_CHANNELS_PER_LISTENER_STREAM];
    for (int i = 0; i < channels_per_stream; i++)
        map[i] = j ? j*channels_per_stream+i : j+i;
    avb.set_source_map(j, map, channels_per_stream);
    avb.set_source_format(j, AVB_FORMAT_MBLA_24BIT, default_sample_rate);
    avb.set_source_sync(j, 0);
    avb.set_source_channels(j, channels_per_stream);
  }

particularly the set_source_map() function, and the way to order the array ?

I've pointed out an error in my FPGA in the sample ordering on TDM time slots. Now this is corrected, audio signal is still not good but more coherent, or let say more easy to analyse : depending on the way (XMOS -> FPGA or FPGA -> XMOS), I have one sample over two that is always zero, or I have a repetition of each odd sample.....

So maybe there is a particular sample ordering inside TDM lanes when at double speed...?

[akp]

I don't have any listeners so I don't care about them at present, but thanks for finding this issue!

[azs]

Well I've copy/pasted Listener source code but I may have done this with Talkers....
This was just a question, not an issue pointed out ! I have really strange behaviors, also see that TDM clock/data timings that where good at 48k are not as good at 96k !
Sometime I miss or have a re-copy each odd samples, sometimes all samples seems to be here in godd order but still have a sign-bit issue (I configured TDM to be 0-clock shift, i.e. left-justified, but I can see with the scope that XMOS output data are 1-clock shifted !! this explain my sign-bit issue).

I cannot figure-out a consistent scenario for now ! Still digging into it..... hard work.