[#4322] Audio Latency on AD1981 with MMAP enabled
Submitted By: Cameron Barfield
2008-08-07 10:13:37 Close Date
Closed Fixed In Release:
Found In Release:
BF537 Silicon Revision:
Is this bug repeatable?:
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.
--- Cameron Barfield 2008-08-19 11:50:01
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
--- 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:
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:
aplay -M peanut.au
--- Cameron Barfield 2008-10-09 10:53:20
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 --
--- 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
--- Cliff Cai 2008-10-16 06:01:26
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
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