addming blinking led to usb_aud_l1 reference design?

[rlim]

I would like to be able to monitor the rate feedback of asynchronous usb2.0 audio via leds. Can someone tell me where I can insert code to output this information to the existing leds on the L1 board? I assume in the decoupler thread but am a bit lost as to how to proceed. What's the difference between decouple.h and decouple.xc? Below is the decouple.h code that's found in the reference design. How does one go about adding the c_led parameter?

Code: Select all

void decouple(chanend c_audio_out,
             // chanend ?c_midi, 
              chanend ?c_clk_int
#ifdef IAP
, chanend ?c_iap
#endif
);

Thanks in advance.

[infiniteimprobability]

I would like to be able to monitor the rate feedback of asynchronous usb2.0 audio via leds. Can someone tell me where I can insert code to output this information to the existing leds on the L1 board? I assume in the decoupler thread but am a bit lost as to how to proceed. What's the difference between decouple.h and decouple.xc? Below is the decouple.h code that's found in the reference design. How does one go about adding the c_led parameter?

The USB Audio reference design packs a lot of functions into the chip, and relies on quite a bit of hand optimisation to make it fit. For example, a single port (32A) handles ULPI reset, CODEC reset, Mclk select as well as the LEDs. see port32A.h

To access the LEDs, two helper functions are provided, audiostream.xc and hostactive.xc. You can see they are pretty similar and do a read modify write to set the LEDs. You can use these functions to access the LEDs but don't forget to remove calls to these from elsewhere.

I'm not exactly sure about what you want to monitor though. The audio is asynchronous which means the MCLK defines the rate of audio, which doesn't change when streaming - our firmware manages buffers and USB transfers to ensure streaming is continuous.

If you want to display sample rate - you could get that from EP0 (in audiorequests.xc called from endpoint0.xc).

If you want to monitor rates of reading/writing and buffer levels - decouple.xc is a good place to get this info. It is triggered (using an interrupt) from c_mix_out which comes from the audio core which controls the audio rate. It reads/writes the buffers handled by usb_buffer.xc. It signals via shared memory regarding the state of the buffer, as well as when request/send more data.

One word of warning however - don't put too much extra code in the datapath. Whilst it can handle 16+ channels of audio OK, putting too much code in there may break timing. In the basic ref design, (2 in 2 out with MIDI & SPDIF disabled) you only need 5 cores to you have a spare core to put code in without having to worry about timing, as long as any communication doesn't block.

[infiniteimprobability]

Some additional info...
Having discussed this with colleagues, I think what you may be getting at is the feedback value used to signal how many samples to send. If this is what you are after, then the place to look is usb_buffer.xc. There is a variable in there called fb_clocks, the lower two 16b unsigned words contain the whole and fractional values of the number of samples needed. This is done every 128 SOFs..

If you look at a typical USB trace, this value barely changes during normal operation (which is what you would expect since the clocks don't wander much).

If you would like more on this subject, page two of this article introduces it nicely:
http://www.edn.com/design/consumer/4376 ... -USB-Audio

The USB audio spec is the definitive reference..