[alsa-devel] 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]
Hi again
Allright.. Took me forever doing a bisect in alsa-kmirror while finding the proper revision in alsa-drivers to be able to compile it. So painful.. How do you guys ever manage to quickly do bisect ???
Anyhow...
What broke passthrough for me (and others) is this commit:
commit 1ca3d59d5a3e762fb1c002bcd912914bc858b430 Author: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Date: Thu Aug 4 10:12:56 2011 -0500
ALSA: hda: option to enable arbitrary buffer/period sizes
Add new parameter to disable rounding of buffer/period sizes to multiples of 128 bytes. This is more efficient in terms of memory access but isn't required by the HDA spec and prevents users from specifying exact period/buffer sizes. For example for 44.1kHz, a period size set to 20ms will be rounded to 19.59ms.
Tested and enabled on Intel HDA controllers. Option is disabled by default for other controllers.
Tested-by: Wu Fengguang fengguang.wu@intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Jaroslav Kysela perex@perex.cz
It's not an obvious breakage however and it only occurs with specific combinations of hardware buffer size (as seen for me in /proc/asound/card1/pcm3p/sub0/prealloc) and request of buffer time and period size.
With the default ALSA hardware buffer size of 64kB, AC3/DTS works. With 4096, it doesn't and it will make the tested applications hang.
both MythTV and mplayer (and I know of a few others), request by default a buffer time of 500ms with a period of 4 (requested respectively through snd_pcm_hw_params_set_buffer_time_near and snd_pcm_hw_params_set_periods_near)
With those combinations: (4MB hardware buffer, 500ms and period of 4), trying to write audio with snd_pcm_writei will hang to eventually fail with the error "Input/output error"
Disabling the functionality introduced in that changeset, fix it for v1.0.25 (using the following patch: diff --git a/pci/hda/hda_intel.c b/pci/hda/hda_intel.c index 9cbde2f..9227389 100644 --- a/pci/hda/hda_intel.c +++ b/pci/hda/hda_intel.c @@ -2773,8 +2773,8 @@ static int __devinit azx_create(struct snd_card *card, str }
/* disable buffer size rounding to 128-byte multiples if supported */ - if (chip->driver_caps & AZX_DCAPS_BUFSIZE) - align_buffer_size = 0; +// if (chip->driver_caps & AZX_DCAPS_BUFSIZE) +// align_buffer_size = 0;
/* allow 64bit DMA address if supported by H/W */ if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
)
Hope this help Regards Jean-Yves Avenard
On 12.02.2012 12:25, Jean-Yves Avenard wrote:
Hi again
Allright.. Took me forever doing a bisect in alsa-kmirror while finding the proper revision in alsa-drivers to be able to compile it. So painful.. How do you guys ever manage to quickly do bisect ???
Anyhow...
What broke passthrough for me (and others) is this commit:
commit 1ca3d59d5a3e762fb1c002bcd912914bc858b430 Author: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Date: Thu Aug 4 10:12:56 2011 -0500
ALSA: hda: option to enable arbitrary buffer/period sizes Add new parameter to disable rounding of buffer/period sizes to multiples of 128 bytes. This is more efficient in terms of memory access but isn't required by the HDA spec and prevents users from specifying exact period/buffer sizes. For example for 44.1kHz, a period size set to 20ms will be rounded to 19.59ms. Tested and enabled on Intel HDA controllers. Option is disabled by default for other controllers. Tested-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <perex@perex.cz>It's not an obvious breakage however and it only occurs with specific combinations of hardware buffer size (as seen for me in /proc/asound/card1/pcm3p/sub0/prealloc) and request of buffer time and period size.
With the default ALSA hardware buffer size of 64kB, AC3/DTS works. With 4096, it doesn't and it will make the tested applications hang.
I'm not familiar enough with HDA to comment on the cause of the issue, but out of interest, does the hang really only happen with passthrough, i.e. (AES0 & 0x02) set, or does it happen with a PCM stream with the same parameters as well (and the application(s) just happen to set problematic ALSA parameters only in passthrough mode)?
both MythTV and mplayer (and I know of a few others), request by default a buffer time of 500ms with a period of 4 (requested respectively through snd_pcm_hw_params_set_buffer_time_near and snd_pcm_hw_params_set_periods_near)
With those combinations: (4MB hardware buffer, 500ms and period of 4), trying to write audio with snd_pcm_writei will hang to eventually fail with the error "Input/output error"
Disabling the functionality introduced in that changeset, fix it for v1.0.25 (using the following patch: diff --git a/pci/hda/hda_intel.c b/pci/hda/hda_intel.c index 9cbde2f..9227389 100644 --- a/pci/hda/hda_intel.c +++ b/pci/hda/hda_intel.c @@ -2773,8 +2773,8 @@ static int __devinit azx_create(struct snd_card *card, str }
/* disable buffer size rounding to 128-byte multiples if supported */
if (chip->driver_caps & AZX_DCAPS_BUFSIZE)align_buffer_size = 0;+// if (chip->driver_caps & AZX_DCAPS_BUFSIZE) +// align_buffer_size = 0;
/* allow 64bit DMA address if supported by H/W */ if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64))))
Hope this help Regards Jean-Yves Avenard _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi
On 13 February 2012 00:17, Anssi Hannula anssi.hannula@iki.fi wrote:
I'm not familiar enough with HDA to comment on the cause of the issue, but out of interest, does the hang really only happen with passthrough, i.e. (AES0 & 0x02) set, or does it happen with a PCM stream with the same parameters as well (and the application(s) just happen to set problematic ALSA parameters only in passthrough mode)?
Hi
To be honest, I don't really know for sure.
But I've only experienced it with digital passthrough.
If I disable passthrough, and force the decoding of the AC3 and downmix it as stereo (so it would open the audio card with the same parameters as with passthrough), then I do not see the hang
But I haven't looked into the details very carefully to make sure that it is indeed the case.
I will try more tomorrow..
Hi there
Okay, I had time today to test a bit more on what was going on
On 13 February 2012 00:17, Anssi Hannula anssi.hannula@iki.fi wrote:
I'm not familiar enough with HDA to comment on the cause of the issue, but out of interest, does the hang really only happen with passthrough, i.e. (AES0 & 0x02) set, or does it happen with a PCM stream with the same parameters as well (and the application(s) just happen to set problematic ALSA parameters only in passthrough mode)?
Actually, went through over a lot of different type, only to find that the problem isn't with passthrough as such, but a combination of the prealloc value set and if 16 bits / 32 bits audio.
16 bits audio, as soon as the ALSA hardware buffer is set to something different than the default 64 (like 4096, the default when using Ubuntu) snd_pcm_write will hang then error.
32 bits audio, plays under most combinations tried, except for 5.1 PCM where I had to set the prealloc buffer to 1024 and above to get it work
Here are the various mode I tried, the output of the log is for 4096 prealloc buffer
For a reminder: format=2 -> SND_PCM_FORMAT_S16_LE format=10 -> SND_PCM_FORMAT_S32_LE
AC3 Passthrough: working for 64kB, Not working for: 128, 256, 512, 1024, 2048 and 4096 2012-02-13 15:58:50.339376 I ALSA: SetParameters(format=2, channels=2, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 15:58:50.339437 I ALSA: Buffer size range from 64 to 1048576 2012-02-13 15:58:50.339441 I ALSA: Period size range from 32 to 524288 2012-02-13 15:58:50.339455 I ALSA: Buffer time = 500000 us 2012-02-13 15:58:50.339465 I ALSA: Period time = 4 periods 2012-02-13 15:58:50.458098 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 15:58:50.696838 I AO: Audio fragment size: 12000
16 bits stereo: working for 64, Not working for: 128, 256, 512, 1024, 2048, 4096 2012-02-13 16:20:39.027793 I ALSA: SetParameters(format=2, channels=2, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 16:20:39.027855 I ALSA: Buffer size range from 64 to 1048576 2012-02-13 16:20:39.027859 I ALSA: Period size range from 32 to 524288 2012-02-13 16:20:39.027873 I ALSA: Buffer time = 500000 us 2012-02-13 16:20:39.027883 I ALSA: Period time = 4 periods 2012-02-13 16:20:39.267237 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 16:20:39.507467 I AO: Audio fragment size: 12000
32 bits Stereo: working for: 64, 128,,256, 512, 1024, 2048 and 4096 2012-02-13 16:05:25.010312 I ALSA: SetParameters(format=10, channels=2, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 16:05:25.010372 I ALSA: Buffer size range from 32 to 524288 2012-02-13 16:05:25.010376 I ALSA: Period size range from 16 to 262144 2012-02-13 16:05:25.010389 I ALSA: Buffer time = 500000 us 2012-02-13 16:05:25.010400 I ALSA: Period time = 4 periods 2012-02-13 16:05:25.286857 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 16:05:25.526849 I AO: Audio fragment size: 24000
5.1 16 bits PCM: Using 64kB prealloc buffer, snd_pcm_hw_params_set_buffer_time_near gives the error "Invalid Parameter" for 500000 Not working for 128, 256, 512, 1024, 2048 and 4096
2012-02-13 16:09:11.621562 I ALSA: SetParameters(format=2, channels=6, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 16:09:11.621628 I ALSA: Buffer size range from 22 to 349525 2012-02-13 16:09:11.621632 I ALSA: Period size range from 11 to 174762 2012-02-13 16:09:11.621645 I ALSA: Buffer time = 500000 us 2012-02-13 16:09:11.621663 I ALSA: Period time = 4 periods 2012-02-13 16:09:11.796861 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 16:09:12.036842 I AO: Audio fragment size: 36000
5.1 32 bits PCM: Not working for: 64, 256, 512. Working for 1024, 2048, 4096 128 gives Invalid argument for snd_pcm_hw_params_set_buffer_time_near
2012-02-13 16:25:12.890306 I ALSA: SetParameters(format=10, channels=6, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 16:25:12.890366 I ALSA: Buffer size range from 12 to 174762 2012-02-13 16:25:12.890370 I ALSA: Period size range from 6 to 87381 2012-02-13 16:25:12.890383 I ALSA: Buffer time = 500000 us 2012-02-13 16:25:12.890393 I ALSA: Period time = 4 periods 2012-02-13 16:25:13.066855 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 16:25:13.316823 I AO: Audio fragment size: 72000
_From looking at hda_intel.c, it seems that the problem is that the nvidia set AZX_DCAPS_BUFSIZE in driver_caps when it probably doesn't support it.. Hopefully Stephen will be able to answer that one.
I'm surprised not more people has reported the problem, surely there are a lot of people affected by this... Though 1.0.25 is very recent and not used yet by many linux distribution. Soon this will change :(
Jean-Yves
At Mon, 13 Feb 2012 17:32:03 +1100, Jean-Yves Avenard wrote:
Hi there
Okay, I had time today to test a bit more on what was going on
On 13 February 2012 00:17, Anssi Hannula anssi.hannula@iki.fi wrote:
I'm not familiar enough with HDA to comment on the cause of the issue, but out of interest, does the hang really only happen with passthrough, i.e. (AES0 & 0x02) set, or does it happen with a PCM stream with the same parameters as well (and the application(s) just happen to set problematic ALSA parameters only in passthrough mode)?
Actually, went through over a lot of different type, only to find that the problem isn't with passthrough as such, but a combination of the prealloc value set and if 16 bits / 32 bits audio.
16 bits audio, as soon as the ALSA hardware buffer is set to something different than the default 64 (like 4096, the default when using Ubuntu) snd_pcm_write will hang then error.
32 bits audio, plays under most combinations tried, except for 5.1 PCM where I had to set the prealloc buffer to 1024 and above to get it work
Here are the various mode I tried, the output of the log is for 4096 prealloc buffer
For a reminder: format=2 -> SND_PCM_FORMAT_S16_LE format=10 -> SND_PCM_FORMAT_S32_LE
AC3 Passthrough: working for 64kB, Not working for: 128, 256, 512, 1024, 2048 and 4096 2012-02-13 15:58:50.339376 I ALSA: SetParameters(format=2, channels=2, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 15:58:50.339437 I ALSA: Buffer size range from 64 to 1048576 2012-02-13 15:58:50.339441 I ALSA: Period size range from 32 to 524288 2012-02-13 15:58:50.339455 I ALSA: Buffer time = 500000 us 2012-02-13 15:58:50.339465 I ALSA: Period time = 4 periods 2012-02-13 15:58:50.458098 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 15:58:50.696838 I AO: Audio fragment size: 12000
16 bits stereo: working for 64, Not working for: 128, 256, 512, 1024, 2048, 4096 2012-02-13 16:20:39.027793 I ALSA: SetParameters(format=2, channels=2, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 16:20:39.027855 I ALSA: Buffer size range from 64 to 1048576 2012-02-13 16:20:39.027859 I ALSA: Period size range from 32 to 524288 2012-02-13 16:20:39.027873 I ALSA: Buffer time = 500000 us 2012-02-13 16:20:39.027883 I ALSA: Period time = 4 periods 2012-02-13 16:20:39.267237 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 16:20:39.507467 I AO: Audio fragment size: 12000
32 bits Stereo: working for: 64, 128,,256, 512, 1024, 2048 and 4096 2012-02-13 16:05:25.010312 I ALSA: SetParameters(format=10, channels=2, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 16:05:25.010372 I ALSA: Buffer size range from 32 to 524288 2012-02-13 16:05:25.010376 I ALSA: Period size range from 16 to 262144 2012-02-13 16:05:25.010389 I ALSA: Buffer time = 500000 us 2012-02-13 16:05:25.010400 I ALSA: Period time = 4 periods 2012-02-13 16:05:25.286857 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 16:05:25.526849 I AO: Audio fragment size: 24000
5.1 16 bits PCM: Using 64kB prealloc buffer, snd_pcm_hw_params_set_buffer_time_near gives the error "Invalid Parameter" for 500000 Not working for 128, 256, 512, 1024, 2048 and 4096
2012-02-13 16:09:11.621562 I ALSA: SetParameters(format=2, channels=6, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 16:09:11.621628 I ALSA: Buffer size range from 22 to 349525 2012-02-13 16:09:11.621632 I ALSA: Period size range from 11 to 174762 2012-02-13 16:09:11.621645 I ALSA: Buffer time = 500000 us 2012-02-13 16:09:11.621663 I ALSA: Period time = 4 periods 2012-02-13 16:09:11.796861 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 16:09:12.036842 I AO: Audio fragment size: 36000
5.1 32 bits PCM: Not working for: 64, 256, 512. Working for 1024, 2048, 4096 128 gives Invalid argument for snd_pcm_hw_params_set_buffer_time_near
2012-02-13 16:25:12.890306 I ALSA: SetParameters(format=10, channels=6, rate=48000, buffer_time=500000, period_time=4) 2012-02-13 16:25:12.890366 I ALSA: Buffer size range from 12 to 174762 2012-02-13 16:25:12.890370 I ALSA: Period size range from 6 to 87381 2012-02-13 16:25:12.890383 I ALSA: Buffer time = 500000 us 2012-02-13 16:25:12.890393 I ALSA: Period time = 4 periods 2012-02-13 16:25:13.066855 I ALSA: Buffer size = 24000 | Period size = 6000 2012-02-13 16:25:13.316823 I AO: Audio fragment size: 72000
From looking at hda_intel.c, it seems that the problem is that the
nvidia set AZX_DCAPS_BUFSIZE in driver_caps when it probably doesn't support it..
The problem of Nvidia HDMI and the buffer-alignment was already fixed in the upstream code. Nvidia HDMI is known to be broken with the arbitrary alignment, so it's disabled automatically.
Hopefully Stephen will be able to answer that one.
I'm surprised not more people has reported the problem, surely there are a lot of people affected by this... Though 1.0.25 is very recent and not used yet by many linux distribution. Soon this will change :(
Maybe little people are actually using the released alsa-driver any longer.
Takashi
Hi
On 14 February 2012 00:34, Takashi Iwai tiwai@suse.de wrote:
The problem of Nvidia HDMI and the buffer-alignment was already fixed in the upstream code. Nvidia HDMI is known to be broken with the arbitrary alignment, so it's disabled automatically.
Is the issue believed to be related to nvidia hdmi only ?
I just got the report from a user stating that he had issue playing audio on his Dell Vostro 200, which is pure intel
Maybe little people are actually using the released alsa-driver any longer.
If they are like me, to get the latest stable version of alsa, they go to alsa-project.org and download whatever is there. Today that's 1.0.25 and IMHO, that bug is a massive blocker.. I hope it will be updated soon.
Jean-Yves
Is the issue believed to be related to nvidia hdmi only ? I just got the report from a user stating that he had issue playing audio on his Dell Vostro 200, which is pure intel
This is surprising, the hardware folks at Intel confirmed the rounding to multiple of 128 bytes is not needed and this patch has been there for over 6 months now without generating any complaints. Can you get us more information on that case, and ask this user to see what happens by enabling this rounding again. Thanks, -Pierre
Hi
On 15 February 2012 14:58, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
This is surprising, the hardware folks at Intel confirmed the rounding to multiple of 128 bytes is not needed and this patch has been there for over 6 months now without generating any complaints. Can you get us more information on that case, and ask this user to see what happens by enabling this rounding again.
Seeing that 1.0.25 broke it for any nvidia user and not many people have complained yet, my guess is that it's not much in use yet.
The default ALSA prealloc size is 64, with that value, the problem isn't seen much.
Following the recommendation of the pulseaudio folks, he set the value to 2048, with this value the user reported that it failed with mythtv.
I have asked him more details about his configuration... I'm hoping to be able to pass that information on soon
I will also ask him if he can patch it to disable the rounding and if that makes any differences to him.
Thanks Jean-Yves
participants (4)
-
Anssi Hannula -
Jean-Yves Avenard -
Pierre-Louis Bossart -
Takashi Iwai