Re: [alsa-devel] dmix produces garbled sound on ARM
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.
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
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.)
participants (2)
-
Ihar Filipau -
Takashi Iwai