Audio breaks up on some SD-card writes (Was: cpu usage way too high (?))

Rask Ingemann Lambertsen rask at
Sat Feb 7 15:21:07 CET 2009

On Mon, Feb 02, 2009 at 09:42:04AM +0000, Andy Green wrote:

> |    It also appears than any sort of write to the SD-card (even just 4 kB)
> | can interrupt audio. I don't know if it's down to the hardware or a kernel
> | bug. Reading from the SD-card seems to work fine.
> We do have to sit there spamming the 4KB into the Glamo memory before
> starting the transaction.  But it's not much different from having to
> spam out the 4KB from the Glamo memory on read inside interrupt context
> when notified it completed.

   The problem doesn't get worse with larger writes. For example, just now I
had sound break up for about a second with 'vmstat 1' showing 36 blocks
output. Then 8-10 seconds later, 3964 blocks were output with no sound
problem (that I could hear).

> Maybe the card blocks for a long time after the write, and the next
> command we try doesn't return a status for a long time and we sit
> spinning for it.

   It's a SanDisk card, so I guess that possibility can't be ruled out.
I'm now running a 2.6.28 kernel I compiled from;a=shortlog;h=andy-tracking (snapshot
'fix-pcf50633-set-charging-limit-with-usb-limit.patch') and the problem is
still there. Perhaps you could give me a pointer as to where in the driver
I would try to make a modification (or at least insert some printk to narrow
down the problem)?

   FWIW, to produce some sound I'm using mikmod to play
{Sound,Noise,Pro,Fast,Scream}Tracker modules with the OSS driver (modprobe
snd-pcm-oss). Mikmod has modest CPU requirements, most of the time using
less than 1 % according to 'top', so plain lack of CPU time isn't likely
causing audio dropouts. Out of 10-15 attempts, I've twice managed to break
up the audio with 'dd if=/dev/zero of=/dev/mmcblk0p3 count=1 bs=4k'.

Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

More information about the hardware mailing list