[alsa-devel] dmix produces garbled sound on ARM

[Takashi Iwai]

On Thu, 09 Jun 2016 15:17:53 +0200,
Ihar Filipau wrote:
> 
> On 6/9/16, Takashi Iwai <tiwai at 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-trying-to-use-alsa-dmix
> >> )
> >>
> >> 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.

Hm, then try to adjust all parameters as same as dmix slave PCM.
As default, dmix slave PCM takes 16 x 1024 frames periods, S16_LE
format.

> 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?

If the hw works and dmix doesn't even with the very same parameters
for a single stream, it can be in the update timing.  But it's
doubtful, as basically dmix slave is freewheeling...


Takashi

> 
> Thanks.
>