dmix produces garbled sound on ARM

dmix produces garbled sound on ARM

[Ihar Filipau]

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?

Thanks.

P.S. Versions: Linux v3.18.24, alsa-lib/-utils v1.0.29. The hardware:
FreeScale i.MX35 (ARM1136) with SGTL5000 sound chip (used in 48KHz
mode).

P.P.S. The generic code has outdated functions for the "concurrent"
implementation with cmpxchg. The code probably could be updated, and
revised to use the C11's stdatomic.h when available.

Re: dmix produces garbled sound on ARM

[Takashi Iwai]

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?
> 
> Thanks.
> 
> P.S. Versions: Linux v3.18.24, alsa-lib/-utils v1.0.29. The hardware:
> FreeScale i.MX35 (ARM1136) with SGTL5000 sound chip (used in 48KHz
> mode).
> 
> P.P.S. The generic code has outdated functions for the "concurrent"
> implementation with cmpxchg. The code probably could be updated, and
> revised to use the C11's stdatomic.h when available.

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).

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.


Takashi

Re: dmix produces garbled sound on ARM

[Ihar Filipau]

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

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.

Re: 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@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.
> 

Re: dmix produces garbled sound on ARM

[Ihar Filipau]

On 6/9/16, Takashi Iwai <tiwai@suse.de> wrote:
> On Thu, 09 Jun 2016 16:05:42 +0200,
> Ihar Filipau wrote:
>>
>> The only thing so far I have found is `aplay --dump-hw-params`, but it
>> seem to display the allowed ranges, not the defaults/the params which
>> are used.
>
> You just need to check what "aplay -v ..." shows.  For example,
> % aplay -Dplug:dmix -v foo.wav

[ Replying back to the list, since exchange of the lengthy outputs is
over for now. ]

My parameters are nearly identical to yours (except for the
differences which could be attributed to my 32-bit vs your 64-bit
systems, and the hardware S16_LE vs S32_LE). Yet the problem persists.

I have checked the Raspberry Pi forums/mail list and it seems that
"dmix" works fine there. Thus, the problem might be related to the hw
driver.

How can I localize the problem? Is there any way to intercept the data
stream which goes to the sound card, and compare the content between
normal direct playback vs dmix?

P.S. Though the window is closing for my investigations. I'm starting
to prepare a workaround: applications shouldn't keep pcm open all the
time, should open pcm when needed, and they should retry with a delay
if opening pcm failed.

Re: dmix produces garbled sound on ARM

[Ihar Filipau]

On 6/9/16, Takashi Iwai <tiwai@suse.de> wrote:
> On Thu, 09 Jun 2016 16:05:42 +0200,
> Ihar Filipau wrote:
>>
>> The only thing so far I have found is `aplay --dump-hw-params`, but it
>> seem to display the allowed ranges, not the defaults/the params which
>> are used.
>
> You just need to check what "aplay -v ..." shows.  For example,
> % aplay -Dplug:dmix -v foo.wav

I have just retested it with the "aloop", completely without hardware.
The garbled sound comes from the software, from the dmix/libasound.
The problem is not related to (sound) hardware.

I can upload the garbled output which was recorded by "arecord", if it
would be helpful in analyzing the problem. (12s, ~2MB wav.)

Regards.

Re: dmix produces garbled sound on ARM

[Takashi Iwai]

On Mon, 13 Jun 2016 14:32:30 +0200,
Ihar Filipau wrote:
> 
> On 6/9/16, Takashi Iwai <tiwai@suse.de> wrote:
> > On Thu, 09 Jun 2016 16:05:42 +0200,
> > Ihar Filipau wrote:
> >>
> >> The only thing so far I have found is `aplay --dump-hw-params`, but it
> >> seem to display the allowed ranges, not the defaults/the params which
> >> are used.
> >
> > You just need to check what "aplay -v ..." shows.  For example,
> > % aplay -Dplug:dmix -v foo.wav
> 
> I have just retested it with the "aloop", completely without hardware.
> The garbled sound comes from the software, from the dmix/libasound.
> The problem is not related to (sound) hardware.

Still it is likely a driver problem.  dmix updates are based on ALSA
PCM slave timer, i.e. it's synced with PCM period elapses.  That is,
if the driver updates at a wrong timing, sending the notification
before the sample data has been processed, you'll get the garbled
output as you have.


Takashi

Re: dmix produces garbled sound on ARM

[Ihar Filipau]

On 6/13/16, Takashi Iwai <tiwai@suse.de> wrote:
> On Mon, 13 Jun 2016 14:32:30 +0200,
> Ihar Filipau wrote:
>>
>> On 6/9/16, Takashi Iwai <tiwai@suse.de> wrote:
>> > On Thu, 09 Jun 2016 16:05:42 +0200,
>> > Ihar Filipau wrote:
>> >>
>> >> The only thing so far I have found is `aplay --dump-hw-params`, but it
>> >> seem to display the allowed ranges, not the defaults/the params which
>> >> are used.
>> >
>> > You just need to check what "aplay -v ..." shows.  For example,
>> > % aplay -Dplug:dmix -v foo.wav
>>
>> I have just retested it with the "aloop", completely without hardware.
>> The garbled sound comes from the software, from the dmix/libasound.
>> The problem is not related to (sound) hardware.
>
> Still it is likely a driver problem.  dmix updates are based on ALSA
> PCM slave timer, i.e. it's synced with PCM period elapses.  That is,
> if the driver updates at a wrong timing, sending the notification
> before the sample data has been processed, you'll get the garbled
> output as you have.
>

But the PCM in the case is the "aloop"? Or not? What other hardware is
involved in the process?

For the sake of a test, I have deactivated the SGTL5000 sound driver,
leaving only the "aloop" as sound device: the result hasn't changed.
But now there is only ALSA software + kernel which are involved.

I have also tried tickless vs fixed HZ kernels (CONFIG_NO_HZ=y vs
CONFIG_HZ_1000=y) but it didn't change anything. The result is the
same.

P.S. I have uploaded the sound file:

http://vocaroo.com/i/s1cU2DRVgJNw

This is supposed to be first 12 seconds of "Annie Lennox - Honestly"
song. (Outside the Germany, it should be readily available on the
YouTube.)