On 6/9/16, Takashi Iwai tiwai@suse.de wrote:
On Thu, 09 Jun 2016 13:38:19 +0200, Ihar Filipau wrote:
Hi All!
When using the dmix on ARM, the sound comes out garbled, with as if overlapping, increasing-in-number echoes. That happens even with a single aplay instance.
In a forum discussion, it was suggested that ARM lacks optimized dmix implementation. But that implies that the generic dmix code is broken, since it is what is used on ARM/etc, but not on i386/amd64. (The forum discussion about my particular issue: http://unix.stackexchange.com/questions/288451/sound-corruption-echo-when-tr... )
Does anybody has any suggestions how to fix/avoid the dmix issue on ARM?
This is likely the cache coherency issue. For example, the generic dmix code works fine on x86-64 if I modify the ifdef condition (I tested now).
Thanks for the test!
I suppose the mmap support is broken with your device / driver. Does "aplay -Dhw -M --period-size=1024 somefile.wav" work? This should show a similar problem.
The command plays the audio perfectly well.
The hardware works, and it worked for quite some time now. But apparently it doesn't support the hardware mixing (I'm not even sure how to check that, found no documentation) while now we need the audio playback from two applications. The second applications gets -EBUSY when trying to open the "default" pcm. I have tried the 'dmix' - e.g. "aplay -Dplug:dmix somefile.wav" . With that I can open the pcm multiple times - "for X in 1 2 3 4; do aplay -Dplug:dmix somefile.wav & ; done" - but the sound is garbled, whether it is a single aplay or multiple aplays.
Is there any other way I can debug/trace the alsa to shed light on the problem I'm having?
Thanks.