[#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

Priority:

Medium Assignee:

Cliff Cai

Status:

Closed Fixed In Release:

2008R1-RC8

Found In Release:

2008R1-RC8 Release:

Category:

Audio Board:

N/A

Processor:

BF537 Silicon Revision:

all

Is this bug repeatable?:

Yes Resolution:

Out of Date

Uboot version or rev.:

Toolchain version or rev.:

trunk

App binary format:

N/A

Summary: Audio Latency on AD1981 with MMAP enabled

Details:

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:

blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&forum_id=39&_forum_action=ForumMessageBrowse&thread_id=28745

Follow-ups

--- 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.

Cliff

--- 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

Cameron:

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

muted? (Codec volume is set to zero)?

-Robin

--- 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

Cameron:

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...

-Robin

--- 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

done

This also causes the same situation as linphone/mediastream.

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

Cameron,

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

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

Cameron,

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

done

Cliff

--- 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

Cameron,

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

script

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.

Thanks

Cliff

--- 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

--- 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

-p0,

if you want have a try.

Cliff

--- 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

reset/re-

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

So,codec can keep in fresh state.

Cliff

--- 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

--- 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

open.

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);

udelay(100);

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]);

udelay(100);

}

Cliff

Files

Changes

Commits

Dependencies

Duplicates

Associations