USB audio feedback endpoint

[beandigital]

Hi

I have a USB 2.0 audio design that uses a feedback endpoint. I am having some trouble as the feedback isn't working very well.
The design uses a 44.1kHz audio clock. I am counting the number of audio clocks for 8 SOFs (uFrames).
So in 8 SOF I should get a value of around 44 (5.5 clocks per uFrame * . Sometimes it may be say 43 or 45.
I takes this value which in binary is 0010 1100 and convert it into the 16.16 format. So the 3 LSBs make 0x8000 and the 5 MSBs 0x0005.
I am using this design with a Cypress FX3 (USB2 only mode) and an FPGA.
I have a sample buffer in the FPGA but it is all over the place. Sometimes becoming full then going to empty. I would expect it to be settled around a certain sample size. Say 16 samples plus/minus 1.
I am using a Thesycon driver and using their spy tool I can see that the feedback values are what I stated above, so I am not sure what the problem is.
Any help much appreciated.

Thanks

Jon

[Tsuneo]

I am counting the number of audio clocks for 8 SOFs (uFrames).
So in 8 SOF I should get a value of around 44 (5.5 clocks per uFrame * 8 )

You are capturing the audio sampling timing (Fs = 44.1kHz) directly at every 8 micro-frames. It doesn't give enough precision to satisfy the requirement of the feedback. Low-precision feedback makes the audio host unstable, because every feedback data alters in greater scale unexpectedly. It causes distorted sound.

The required precision of HS feedback is K=13 (13 bits under the decimal point), described in "5.12.4.2 Feedback" chapter on the USB2.0 spec. To achieve this precision in short period capturing, master clock, instead of sampling clock, is captured. Suppose that the sampling clock (Fs = 44.1 kHz) derives from a master clock (256 Fs = 11.2896 MHz).
256 = 2^8
13 - 8 = 5
2^5 = 32
And then you can achieve the required precision by capturing at every 32 SOF interval.
The device tells this interval to host at the bInterval field of the feedback endpoint descriptor. (bInterval = 6: 2^(6-1) = 32)

Tsuneo

[beandigital]

Thanks for your reply.
So what value would I send in the feedback data? Would it be the 11.2896 MHz count over 32 SOF? So I would get 11.2896MHz/8kHz * 32 = 45152.

45152 = 0b 1011 0000 0110 0000

Thanks

Jon

[Tsuneo]

So what value would I send in the feedback data?

The feedback data is the ratio of sampling frequency / SOF frequency.
It is the number of samples in every isoc OUT transaction (ie. data rate).

44.1 kHz / 8 kHz (micro-frame) = 5.5125

The device gives this figure in (16.16) fixed point format.

5.5125 * 2^16 = around 0x0005 8333

As of the 256 Fs master clock system,

Code: [Select]

                              1)
Master clock source (256 Fs) ---> a counter (free run)
                                     ||
                                  2) || <-- gated by SOF at every 32 micro-frame
                                     ||
                                 captured value
                                      |           4)            5)
                                   3) |----> 3bits left shift ---> feedback value
                                      |
                                subtract last captured value
1) The master clock is fed to a counter as its clock source. (This counter runs without reset)
2) At every 32 SOF timing, the counter value is captured
3) To get the counts of this period, the last captured value is subtracted from the new captured value
4) To fit to 16.16 fixed point format, 3bits left shift is applied
5) Lastly, the calculated value is supplied to the feedback EP

Tsuneo

[beandigital]

The audio driver I am using supports a max bInterval of 4, so that means the I can have a max of 8 uframes. With this value and working back

4 = 2^(4-1) = 8
8 = 2^3
3 = 13 - 10
2^10 = 1024

So it looks like I would need a master clock of 1024 * Fs = 44100 * 1024 = 45,158,400.
This seems to be getting quite large. I guess its still possible in the FPGA but is there an alternative?

Thanks

Jon

[Tsuneo]

Full-speed isoc endpoints, streaming and feedback.
Audio2.0 spec also accepts FS endpoints.
Required feedback precision reduces into K=10, 10 bits under the decimal point.
And then, you may reduce the master clock frequency, to achieve this precision.

Tsuneo

[beandigital]

Tsuneo

My design is not a conventional USB audio system. I have no DAC for example that I am clocking the data out at 44.1 kHz. The data is being sent over  a fibre optic cable using a 125 MHz clock. Each of the 44100 audio samples will have an approx period of 1/44100 as the samples are packed to give this. So I am a little unsure of how I would do about setting the feedback value. This is why I was using a 44.1 kHz clock to begin with. I was just toggling a pin each time a sample was sent out on the cable which gave the 44.1 kHz clock. But you said that there wasn't enough precision. I have tried again by creating a 11.2890 MHz clock from a PLL but I am not sure that it will work correctly as it doesn't seem to be related to the output data.  I can't count the 125 MHz clock as its not a power of 2 of the sample clock. SO if you have any advice I would appreciate it.

Thanks

Jon

 

[Tsuneo]

I have no DAC for example that I am clocking the data out at 44.1 kHz.

No problem.
The USB Audio spec doesn't limit the data Sink device as a DAC. Data transfer interface like SPD/IF will do.

I have tried again by creating a 11.2890 MHz clock from a PLL

PLL isn't the way I suggested.
How do you make the 44.1 kHz (Fs) clock?
What is the master clock from which this Fs derives?
The master clock of this Fs should be captured to make the feedback value.

I can't count the 125 MHz clock as its not a power of 2 of the sample clock.

Again, no problem.
A divisor of a power of 2 is chosen just to make the design simple.
You may divide the captured count by any number, other than a power of 2.

Sound like you are making the 44.1kHz Fs from 125 MHz master clock.
If you would directly divide the master clock,
125MHz / 2834 = 44.1072.. kHz
The captured value of above scheme should be also divided by 2834.

But if you would make the Fs using a PLL, the clock source of capture depends on the PLL configuration. In this case, figure out the PLL configuration to discus on the clock source.

Tsuneo

[beandigital]

So I think that you are saying that I just modify the count to account for the clock.
If I take the example were I use a 45,158,400 master clock and 8 uframes, then if I instead use the 125,000,000 clock I need to modify the count by

125,000,000/45,158,400 = 2.76.

So whatever count I get after 8 uframes I reduce it by a factor of 2.77

So 125,000,000/8000 * 8 uframes = 125000 = count over 8 uframes
125000/2.77 = 45126 = actual count required

Thanks

Jon

[Tsuneo]

Where the sampling clock Fs derives from a master clock by a N divider,
The feedback value is calculated using a counter value clocked by the same master clock.
The counter is captured at SOF timing. Captured value is divided by N, the same number as to make the Fs.
The result of division is formatted to (16.16) fixed-point for HS, or (10.14) for FS.
The formatted value is fed to the feedback endpoint.

Code: [Select]

Master clock -+--> Divider (N) ---> Sampling clock (Fs)
              |
              +--> Counter ===> Captured value ===> Divide by N ===> Shift to HS (16.16) ===> feedback
                            ^                                        or FS (10.14) format
                            |
                      capture gated by SOF

Tsuneo

[beandigital]

I have a question about the data coming in from USB. Would you expect to have to modify the incoming data rate at all for buffer under/over flow? I would think that there shouldn't be any under/over flow as the feedback should take care of that.

Jon

[Tsuneo]

I would think that there shouldn't be any under/over flow as the feedback should take care of that.

Good question ;-)

The feedback value has finite precision under decimal point, though the real ratio of sampling / SOF frequency should be infinite decimal. This "error" may cause over-/under-flow of the buffer in very long term.

The required precision of the feedback (FS:K=10, HS:K=13) is determined, so that the margin of error drops within +/- one sample per second, at most. And then, you'll have a "buffer keeping" process, which runs at every second (1024 frames or 8192 micro-frames).

Simple implementation of this process is,
- At the "buffer keeping" timing, the buffer pointer is examined.
- If the pointer is advanced than expected, reuse the last sample to keep the pointer.
- If the pointer is behind, skip one sample to catch up.

Tsuneo

[beandigital]

At the moment I am using the USB driver in a mode were it has a USB IN and OUT endpoint. The driver looks at the data on the IN endpoint and sets the sample rate of the OUT endpoint. So there is no feedback endpoint used. I am finding that over a 1 second interval I am getting around 20 extra samples (44120 rather than the ideal 44100). So I think that I may have to have my own mechanism for sending more or less samples as otherwise the buffer I have will overflow. The only other solution I can think of is if I were to just discard the extra samples every 1 second. But would this impact the audio quality? I guess 20 samples isn't many in the scheme of things, but if they were all discarded in one go rather than over 1 second then maybe it would be audible?

Jon

[Tsuneo]

I am finding that over a 1 second interval I am getting around 20 extra samples (44120 rather than the ideal 44100).

But it sounds like a problem of the PC driver, if the device would give correct feedback (or IN) value.

Tsuneo