[alsa-devel] dmix and sounds less than 64kb
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.
Thanks much, caustik
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...
Takashi
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.
On 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...
Takashi
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.
Jaroslav
On 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
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
On Tue, 10 Jul 2007, Aaron "Caustik" Robinson wrote:
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?
The cache flush method is quite CPU specific, you have to check datasheet. But it's only guess and the problem might be somewhere else. I would compare samples DMA ring buffer in the user space and kernel space again. Also, put a debug lines to dmix plugin to detect where are samples written (to which pointer/area in the DMA ring buffer). dmix assumes that playback is running forever and tries to mix data in actual ring buffer position.
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
We have found that the problem exists because, at certain points in time, the hardware pointer and application pointer overlap. Basically the hardware is reading from the period buffer which is currently being written to. How might this be platform specific? Is there any debugging technique you think may help find the root cause?
On 7/10/07, Jaroslav Kysela perex@suse.cz wrote:
On Tue, 10 Jul 2007, Aaron "Caustik" Robinson wrote:
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?
The cache flush method is quite CPU specific, you have to check datasheet. But it's only guess and the problem might be somewhere else. I would compare samples DMA ring buffer in the user space and kernel space again. Also, put a debug lines to dmix plugin to detect where are samples written (to which pointer/area in the DMA ring buffer). dmix assumes that playback is running forever and tries to mix data in actual ring buffer position.
Jaroslav
Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
Looking at snd_pcm_dmix_sync_area - if I dump all of the raw pcm data going into the "mix_areas" function call - the data is correct. However, by the time the data gets to the driver it is corrupted. Where does the data go between mix_areas and the driver? I can't seem to track down where next to check the data.
On 7/19/07, Aaron Caustik Robinson caustik@gmail.com wrote:
We have found that the problem exists because, at certain points in time, the hardware pointer and application pointer overlap. Basically the hardware is reading from the period buffer which is currently being written to. How might this be platform specific? Is there any debugging technique you think may help find the root cause?
On 7/10/07, Jaroslav Kysela perex@suse.cz wrote:
On Tue, 10 Jul 2007, Aaron "Caustik" Robinson wrote:
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?
The cache flush method is quite CPU specific, you have to check datasheet. But it's only guess and the problem might be somewhere else. I would compare samples DMA ring buffer in the user space and kernel space again. Also, put a debug lines to dmix plugin to detect where are samples written (to which pointer/area in the DMA ring buffer). dmix assumes that playback is running forever and tries to mix data in actual ring buffer position.
Jaroslav
Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
At Thu, 19 Jul 2007 12:59:32 -0700, Aaron "Caustik" Robinson wrote:
We have found that the problem exists because, at certain points in time, the hardware pointer and application pointer overlap. Basically the hardware is reading from the period buffer which is currently being written to. How might this be platform specific? Is there any debugging technique you think may help find the root cause?
It sounds unlikely a platform-specific problem but rather a problem of the driver implementation.
Note that the hw_ptr and appl_ptr tracked in pcm struct are within 0 and (runtime->boundary_size - 1). It's not within 0 and (buffer_size-1). So, basically it shouldn't overlap unless it goes across the boundary close to long (32bit or more).
Takashi
On 7/10/07, Jaroslav Kysela perex@suse.cz wrote:
On Tue, 10 Jul 2007, Aaron "Caustik" Robinson wrote:
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?
The cache flush method is quite CPU specific, you have to check datasheet. But it's only guess and the problem might be somewhere else. I would compare samples DMA ring buffer in the user space and kernel space again. Also, put a debug lines to dmix plugin to detect where are samples written (to which pointer/area in the DMA ring buffer). dmix assumes that playback is running forever and tries to mix data in actual ring buffer position.
Jaroslav
Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I dumped appl_ptr and slave_appl_ptr being sent to mix_areas - and the numbers flow around the ring buffer in a steady circle. Here are graphs of the data:
http://www.caustik.com/alsa/scat-appl_ptr.gif http://www.caustik.com/alsa/scat-slave_appl_ptr.gif
So it looks like those values are moving like they should. However, I do not know where to print the hardware pointer value. Where is that variable?
Btw - I noticed that the kernel in core audio will manipulate some buffer pointers based on when the buffer is almost drained - is that relevant?
caustik
On 7/24/07, Takashi Iwai tiwai@suse.de wrote:
At Thu, 19 Jul 2007 12:59:32 -0700, Aaron "Caustik" Robinson wrote:
We have found that the problem exists because, at certain points in
time,
the hardware pointer and application pointer overlap. Basically the
hardware
is reading from the period buffer which is currently being written to.
How
might this be platform specific? Is there any debugging technique you
think
may help find the root cause?
It sounds unlikely a platform-specific problem but rather a problem of the driver implementation.
Note that the hw_ptr and appl_ptr tracked in pcm struct are within 0 and (runtime->boundary_size - 1). It's not within 0 and (buffer_size-1). So, basically it shouldn't overlap unless it goes across the boundary close to long (32bit or more).
Takashi
On 7/10/07, Jaroslav Kysela perex@suse.cz wrote:
On Tue, 10 Jul 2007, Aaron "Caustik" Robinson wrote:
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?
The cache flush method is quite CPU specific, you have to check
datasheet.
But it's only guess and the problem might be somewhere else. I would compare samples DMA ring buffer in the user space and kernel space
again.
Also, put a debug lines to dmix plugin to detect where are samples
written
(to which pointer/area in the DMA ring buffer). dmix assumes that
playback
is running forever and tries to mix data in actual ring buffer
position.
Jaroslav
Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (3)
-
Aaron "Caustik" Robinson -
Jaroslav Kysela -
Takashi Iwai