McASP dead periods when streaming through network interface

The first thing I would do is:

- replace GSTREAMER with something else.

Something simplier, something easy to debug. Some handmade code.

For streaming, there must be some buffering of data, and it must be done right.

regards

Wolfgang

Thank you.

According to this, it is likely a problem with the alsasink module of GStreamer.  How did the streaming audio reference design get around this?  I'm trying to test it with pulse audio but not getting any output at all.

Andrew, I would try what Wolfgang suggests and do some tests without G-Streamer. At one point, I was doing some low latency network audio tests with AM335x, and I had a difficult time getting good results with G-streamer, so I ended up writing some simple custom code that worked very well for me. Also, here are some of the g-streamer pipes I created for the first round of audio streaming demos: http://processors.wiki.ti.com/index.php/Sitara_Linux_Audio_gstreamer. I'm sure it's possible to get g-streamer working well for your application, but maybe there are other routes you can take that will have better performance and require a little less debugging.

Also, I did some tests with pulseaudio and also made some demo tests between am335x and linux PC. The main thing I had to do was put it in system mode, as in this wiki:http://processors.wiki.ti.com/index.php/Sitara_Linux_Audio_pulseaudio. From there, I could configure network audio device in pulseaudio and send and receive data from a linux PC.

Hi,

Thank you for your reply.  I did get Pulse audio working in the end, it's just that it seems to use too much CPU so it creates skips/gaps itself.

I was hoping to use GStreamer as I'm going to have a lot of channels to synchronize across multiple devices...so it would be a lot of custom code.  Basically implementing a lot of GStreamer ourselves, which seems kind of silly.

I found the pipelines you put on that wiki page helpful when I was first getting started - thank you.

Andrew

Hi,

I don't have the zoomed in picture at the moment, but I was using 24-bit data at 96kHz.  Although I also went lower to see if it was a bandwidth / data transfer issue too.  The problem scaled down even to 8kHz.  The correct number of bits per frame etc were coming out when I made those changes.

Andrew

I definitely agree.

I should note that the clock and frame sync keep going when there are gaps on the data line...and I modified the alsasink GStreamer plugin to detect when the buffer was full of only 0 values.  It was never full of 0 values during a "stream" from disk (via filesrc), but often full of 0 values during a stream even over the localhost (udpsink, udpsrc, localhost:5000).

I'm not sure if you saw my link above to a known bug in alsasink: link

I tried using the pulse audio sink and it seems the dev board does not have enough CPU power to handle that.

Andrew

Hi,

I finally got a chance to measure the frame sync frequency and it did NOT match the sampling rate.

For a 96kHz file, it was 250MHz.  The ratio of 250/96 is equal to the duty cycle of sound vs blank spots.  So I think you were right to suspect this issue.

I went back through the example and found that I had set the clock frequency of the McASP in the device tree to 12MHz instead of 24MHz.  I did that based on advice I found somewhere while debugging, but I think that was bad advice.

Anyway, now when I play my 96kHz file through gstreamer, the frame sync is at 100kHz.  When I play a 48kHz file using aplay, the frame sync is at 50kHz.

During the 96kHz file, there are again gaps -- 96% of the period is the data, with 4% at 0, which must correspond to the clock rate being 100kHz vs 96kHz.

What do I have wrong that would cause that small difference?

The example documents where it sets the BCLK divider, and says it does not set MCLK or the BCLK/LRCLK ratio:

Notice that we are only setting clock divider "1"; this is because the 24 MHz MCLK (which comes directly from the 24 MHz sysclk), doesn't need to be altered for our configured. Clock divider "2" is the bit clock / frame sync ratio, but it will be updated automatically when we set the bit clock based on the format of the audio to be played, so we don't need to set it here.

Andrew

If you drive the McASP with 24 MHz Clock, and you have an I2S frame of 2 x 24 = 48 bits, and a sample frequency of 48KHz, you need a divider of:

24000000 / 48 / 48000 = 10.4166666.

The McASP driver will select the nearest divider of 10, and this will give you 50 KHz sample frequency == 50 KHz frame rate.

If you want to have 48 KHz, you will need a McASP frequency of n * 2304000Hz. You might need a PLL to connect to the McASP clock to do this.

This requirement is the cause why audio codec chips have a PLL building block. You can generate the McASP frequency from your codec.

Andrew,

Wolfgang is right. Starting from the internal 24 MHz clock it is difficult (if not impossible) to get to some of the standard audio sampling rates if you want the AM335x to be the clock master and source the bit clock and frame sync clock.

Can the codec that you are planning to interface to source the bit clock and the frame sync clock? This is what we do with the TLV320AIC3106 codec that we put on our EVMs. This codec has the ability to specify a fractional value as a divisor which allows it to create the exact frame sync frequencies for most standard audio formats. 

It is possible to bring an additional clock frequency into the McASP and use that instead of the 24 MHz internal clock but the codec route is usually the most straight forward.

Jason Reeder

HI,

Sorry for the late reply - I was out sick.

Thank you Wolfgang and Jason - that makes complete sense.  Yes, our codec can drive the clock...I just don't have one ready to test yet...but it seems like once that is in place things might actually be okay...and then I can get back to the original problem of streaming over Wi-Fi :-)

Andrew

Can you check the Interface Configuration Register at 0x4C000054? What's its value at run-time?

Thank you for following up.

I haven't yet, unfortunately I've been focused on other projects.  I will take a look when I can get back to it.

Andrew