This is on an embedded ARM device, with a custom driver. That's interesting. I never thought about the cache angle. Is there any sort of hack I can put to check if that is the problem?
On 7/10/07, Jaroslav Kysela perex@suse.cz wrote:
On Mon, 9 Jul 2007, Aaron "Caustik" Robinson wrote:
We actually dumped the pcm data as it was arriving to the driver (via
the
trigger start and irq functions), and it was corrupted at that point.
Also I
have dumped the pcm data after it has been mixed by the dmix plugin, and
it
is fine there as well.
Which hardware and driver? It seems like a driver (wrong pointer management) or hardware issue. For example, ARM CPUs does not guarantee cache coherency between two virtual address spaces pointing to one physical space.
JaroslavOn 7/9/07, Takashi Iwai tiwai@suse.de wrote:
At Fri, 6 Jul 2007 20:28:13 -0700, Aaron "Caustik" Robinson wrote:
We have been having one heck of a time tracking down the cause of
some
ALSA
audio playback issues.
It appears that any time we play a very short sound (<64kb), either
the
sound doesn't play at all, or only a fragment of it plays. We
haven't
had
much luck finding a solution to this issue, then I found this thread
on
the
history of this email group:
http://mailman.alsa-project.org/pipermail/alsa-devel/2007-April/000526.html
Our problem is pretty much exactly like his issues relating to <64k
sounds.
My question is - has anybody else run into this problem? To the OP
of
the
above thread, if you're still listening - did you ever find a
solution
to
your problem? I'd be very interested to hear any help you can
provide.
It works fine with my systems, so the problem should be pretty driver-specific...
Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs