[#4322] Audio Latency on AD1981 with MMAP enabled

Document created by Aaronwu Employee on Aug 29, 2013
Version 1Show Document
  • View in full screen mode

[#4322] Audio Latency on AD1981 with MMAP enabled

Submitted By: Cameron Barfield

Open Date

2008-08-07 10:13:37     Close Date

2009-11-17 22:21:35


Medium     Assignee:

Cliff Cai


Closed     Fixed In Release:


Found In Release:

2008R1-RC8     Release:


Audio     Board:



BF537     Silicon Revision:


Is this bug repeatable?:

Yes     Resolution:

Out of Date

Uboot version or rev.:

    Toolchain version or rev.:


App binary format:


Summary: Audio Latency on AD1981 with MMAP enabled



With MMAP enabled (DMA mode) on the AD1981, there is +/- 250ms of delay between writing data to alsa and audio starts coming out of the AD1981.


Can be traced by by running Linphone or mediastreamer. I added some code in mediastreamer2/alsa.c to toggle a GPIO line in alsa_write_process() and hooked that line to a digital probe on my oscilloscope. I've also hooked an analog probe up to the speaker on my board.


I'm seeing a delay of about 250ms from alsa_write_process() to the audio actually coming out of the speaker.


If I turn off MMAP/DMA for the AD1981, there's only about 20-40ms of delay between alsa_write_process() and audio coming out of the speaker.


Background here:





--- Cameron Barfield                                         2008-08-19 11:50:01

Cliff --


The patch you sent me on 15 August seems to fix everything. Thanks.


--- Cliff Cai                                                2008-08-21 02:29:06

Good,I will apply it to trunk later,since the driver in trunk is different from

branch now.




--- Cameron Barfield                                         2008-10-02 12:22:57

If we leave linphone/mediastream running for 48 hours, audio stops playing. We

have plenty of free memory and we're still receiving the RTP Stream, we're just

not playing it out the codec anymore.


We had this problem a while back and it was fixed. I think this patch

reintroduced it. I'm still running with the patch applied to the 2008 branch,

though. I don't know if it's present in the trunk.


--- Robin Getz                                               2008-10-05 19:20:56



Once Audio has stopped, can you tell if it is stopped (no data out SPORT) or

muted? (Codec volume is set to zero)?




--- Cameron Barfield                                         2008-10-06 11:02:16

I'll have to hook up a scope to see if any data is coming out of the sport.


Amixer says everything is set correctly and resetting the values (master 31,31

pcm playback switch on, etc) does not recover the audio.


I retried with the latest trunk over the weekend and get the same results.


--- Cameron Barfield                                         2008-10-06 16:16:47

We've verified there is no activity on the line outs

There was a roughly 5.3V p-p clock on the BCLK line at 12.3MHz

The SYNC was kicking at 48kHz

the SDO was transferring what looked like data to the chip at ~5V p-p

We saw nothing on the SDI line

The chip wasn't in reset.


Also, a soft reboot (reboot at the console) does not resolve the problem. We

actually have to power cycle the unit. When the unit is in the failed state, we

can hear the speaker 'pop' with each command to change the volume.


--- Robin Getz                                               2008-10-06 17:00:14



5.3? or 3.3V the Digital I/O should be 3.3V +/- 10%.


OK - it looks like the codec got confused - so the SPORT seems OK...




--- Cameron Barfield                                         2008-10-06 18:05:56

Sorry, the SDO is around 3.5-3.6v. We are seeing 5v on BCLK, but we're pretty

sure it's our scope getting confused on the fast signal.


--- Cameron Barfield                                         2008-10-08 14:24:28

As another test I ran a script that looped aplay in mmap mode:


while true


    aplay -M peanut.au



This also causes the same situation as linphone/mediastream.



--- Cliff Cai                                                2008-10-09 04:58:53



If running linphone can also cause this problem?

Since in mmap mode,the driver would never stop SPORT/DMA during playing.

so only stopping/restarting application can stop/restart SPORT/DMA.

if running above script also need around 48 hour to reproduce it?

is there any quick way?




--- Cliff Cai                                                2008-10-09 06:03:55



I reproduced the problem quickly(within 1 minute) when I ran same thing

as your script did,but if I added 1 second interval between stopping/starting

a new play,it wouldn't happen for a long time. I will leave it run for all

night and tell you the result.


my script looks like:


while true


    aplay -M peanut.au

    sleep 1






--- Cameron Barfield                                         2008-10-09 10:53:20

Cliff --


Using my script and using linphone, I've seen the problem occur anywhere from 2

hours to 60 hours after starting.


--- Cliff Cai                                                2008-10-10 01:10:06



I don't think it's this patch that reintroduced the problem,I tested the


on latest 2008r1 without this patch ,still saw it.Could you tell me which

revision did you use that hasn't this problem.I need to check the difference.






--- Cameron Barfield                                         2008-10-10 12:21:38

Kernel checkout 4479 and distro checkout 6421, both on 2008R1 branches, did not

appear to have this problem


--- Cameron Barfield                                         2008-10-15 20:08:03

Hi, Cliff --


Any updates?


--- Cliff Cai                                                2008-10-16 02:20:11

Not yet,I'm still investigating this weird problem,I will update it as soon as I

go further.




--- Cliff Cai                                                2008-10-16 06:01:26

Hi Cameron,


There is a patch,it seems ok for running the aplay script,I'm not sure if it

works for linphone,I'm still running it.You can apply it under ../soc with


if you want have a try.





--- Cliff Cai                                                2008-10-20 22:04:51

I've tried linphone on latest 08r1 driver with attached patch several times.

it seems linphone can work over 24 hours without problem.This new patch


config(with the cached shadow registers' value)the codec when open the device,

So,codec can keep in fresh state.




--- Cameron Barfield                                         2008-10-21 11:29:23

Hi, Cliff --


That's good news and sounds like it would fix the problem. I'm in the middle of

a project now but I will grab the patch later this week and give it a shot.


Apply to 2008R1?


--- Cameron Barfield                                         2008-12-15 14:41:37

Cliff --


I applied the patch. Linphone cut out on me after about 72 hours.


Also, this new patch appears to greatly lower the microphone gain.


--- Cliff Cai                                                2009-01-13 21:17:11

I will take a look at this in recent days.




--- Cliff Cai                                                2009-01-19 04:13:17

1.Exactly,Linphone will cut after about 72 hours,it's really hard to know

what has happened at that time,this patch will reset the codec at the next


2.I forgot to restore MIC volume register when reset the codec,

so,adding a line to function 'bf5xx_reset_codec' in bf5xx-pcm.c after having

applied the patch would fix it.


things like these:


static void bf5xx_reset_codec(struct sport_device *sport)


    u16 *cache = sport->codec_reg_cache;

    bf5xx_ac97_write(NULL, 0, 0);


    bf5xx_ac97_write(NULL, 0x74, 0x9900);

        bf5xx_ac97_write(NULL, 0x02, (u16)cache[0x02 >> 1]);

        bf5xx_ac97_write(NULL, 0x0e, (u16)cache[0x0e >> 1]);

    bf5xx_ac97_write(NULL, 0x18, (u16)cache[0x18 >> 1]);

    bf5xx_ac97_write(NULL, 0x1c, (u16)cache[0x1c >> 1]);


















File Name     File Type     File Size     Posted By

cut_latency.patch    text/x-patch    8358    Cliff Cai