1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

[Jean-Yves Avenard]

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

Re: 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

[Anssi Hannula]

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
> 


-- 
Anssi Hannula

Re: 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

[Jean-Yves Avenard]

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

Re: 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

[Jean-Yves Avenard]

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

Re: 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

[Takashi Iwai]

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

Re: 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

[Jean-Yves Avenard]

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

Re: 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

[Pierre-Louis Bossart]

> 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

Re: 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]

[Jean-Yves Avenard]

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