1.0.16->1.0.17 regression for some HDA NVidia's

1.0.16->1.0.17 regression for some HDA NVidia's

[Ozan Çağlayan]

Everything seems OK with those onboard audio chipsets but there's 
absolutely no sound.
We have 2 bug reports on our bug tracking system indicating this 
regression for MCP51, MCP61 and MCP73.

Here are the URL's for alsa-info.sh output's:

MCP51: http://pastebin.ca/1062418
MCP61: http://pastebin.ca/1058482
MCP73: http://pastebin.ca/1058319

Those users have recently reported that downgrading to 1.0.16 series 
solves the problem.

I have an ASUS mainboard which contains the MCP51 one, I can help if you 
want me to rebuild the driver with a patch, or anything else.

Thanks.

--
Ozan Caglayan
<ozan_at_pardus.org.tr>
http://www.pardus.org.tr/eng

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Takashi Iwai]

At Sun, 06 Jul 2008 19:18:01 +0300,
Ozan Çağlayan wrote:
> 
> Everything seems OK with those onboard audio chipsets but there's 
> absolutely no sound.
> We have 2 bug reports on our bug tracking system indicating this 
> regression for MCP51, MCP61 and MCP73.
> 
> Here are the URL's for alsa-info.sh output's:
> 
> MCP51: http://pastebin.ca/1062418
> MCP61: http://pastebin.ca/1058482
> MCP73: http://pastebin.ca/1058319
> 
> Those users have recently reported that downgrading to 1.0.16 series 
> solves the problem.

Could you run alsa-info.sh on 1.0.16, too?  Then we can compare
between working and non-working states.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Ozan Çağlayan]

Takashi Iwai wrote:
> At Sun, 06 Jul 2008 19:18:01 +0300,
> Ozan Çağlayan wrote:
>   
>> Everything seems OK with those onboard audio chipsets but there's 
>> absolutely no sound.
>> We have 2 bug reports on our bug tracking system indicating this 
>> regression for MCP51, MCP61 and MCP73.
>>
>> Here are the URL's for alsa-info.sh output's:
>>
>> MCP51: http://pastebin.ca/1062418
>> MCP61: http://pastebin.ca/1058482
>> MCP73: http://pastebin.ca/1058319
>>
>> Those users have recently reported that downgrading to 1.0.16 series 
>> solves the problem.
>>     
>
> Could you run alsa-info.sh on 1.0.16, too?  Then we can compare
> between working and non-working states.
>
>
> thanks,
>
> Takashi
>   
Hi,

I've also entered a bug report for this problem which includes the two 
outputs:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4038

Thanks.

-- 

Ozan Çağlayan
<ozan_at_pardus.org.tr>

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Takashi Iwai]

At Tue, 08 Jul 2008 00:31:43 +0300,
Ozan Çağlayan wrote:
> 
> Takashi Iwai wrote:
> > At Sun, 06 Jul 2008 19:18:01 +0300,
> > Ozan Çağlayan wrote:
> >   
> >> Everything seems OK with those onboard audio chipsets but there's 
> >> absolutely no sound.
> >> We have 2 bug reports on our bug tracking system indicating this 
> >> regression for MCP51, MCP61 and MCP73.
> >>
> >> Here are the URL's for alsa-info.sh output's:
> >>
> >> MCP51: http://pastebin.ca/1062418
> >> MCP61: http://pastebin.ca/1058482
> >> MCP73: http://pastebin.ca/1058319
> >>
> >> Those users have recently reported that downgrading to 1.0.16 series 
> >> solves the problem.
> >>     
> >
> > Could you run alsa-info.sh on 1.0.16, too?  Then we can compare
> > between working and non-working states.
> >
> >
> > thanks,
> >
> > Takashi
> >   
> Hi,
> 
> I've also entered a bug report for this problem which includes the two 
> outputs:
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4038

The first thing to check is that you are using pulse plugin.
Is it intended, and confirmed to work?

The next thing to check is whether 1.0.16 driver works with the same 
environment (1.0.17 lib, utils, etc) -- that is, your 1.0.16 alsa-info
output.  If yes, get alsa-info.sh output again, then install 1.0.17
driver again and re-test.  Get alsa-info.sh output on 1.0.17 again
(for non-working) to compare exactly.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Ozan Çağlayan]

Takashi Iwai wrote:
> At Tue, 08 Jul 2008 00:31:43 +0300,
> Ozan Çağlayan wrote:
>   
>> Takashi Iwai wrote:
>>     
>>> At Sun, 06 Jul 2008 19:18:01 +0300,
>>> Ozan Çağlayan wrote:
>>>   
>>>       
>>>> Everything seems OK with those onboard audio chipsets but there's 
>>>> absolutely no sound.
>>>> We have 2 bug reports on our bug tracking system indicating this 
>>>> regression for MCP51, MCP61 and MCP73.
>>>>
>>>> Here are the URL's for alsa-info.sh output's:
>>>>
>>>> MCP51: http://pastebin.ca/1062418
>>>> MCP61: http://pastebin.ca/1058482
>>>> MCP73: http://pastebin.ca/1058319
>>>>
>>>> Those users have recently reported that downgrading to 1.0.16 series 
>>>> solves the problem.
>>>>     
>>>>         
>>> Could you run alsa-info.sh on 1.0.16, too?  Then we can compare
>>> between working and non-working states.
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>   
>>>       
>> Hi,
>>
>> I've also entered a bug report for this problem which includes the two 
>> outputs:
>>
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4038
>>     
>
> The first thing to check is that you are using pulse plugin.
> Is it intended, and confirmed to work?
>
> The next thing to check is whether 1.0.16 driver works with the same 
> environment (1.0.17 lib, utils, etc) -- that is, your 1.0.16 alsa-info
> output.  If yes, get alsa-info.sh output again, then install 1.0.17
> driver again and re-test.  Get alsa-info.sh output on 1.0.17 again
> (for non-working) to compare exactly.
>   
First the problem is not present when pulseaudio is stopped. And also, 
we can get sound with 1.0.17rc1 too. So briefly:

1.0.16 + pulse -> works well
1.0.17rc1 + pulse -> works well
1.0.17rc1,rc2 + pulse -> No sound.

It seems that something is broken for these chipsets in either alsa or 
pulse tree. Any ideas for your alsa-{driver,lib,plugins} part?

Thanks a lot.

-- 

Ozan Çağlayan
<ozan_at_pardus.org.tr>

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Ozan Çağlayan]

Takashi Iwai wrote:
> At Thu, 10 Jul 2008 19:41:45 +0300,
> Ozan Çağlayan wrote:
>   
>> Takashi Iwai wrote:
>>     
>>> At Tue, 08 Jul 2008 00:31:43 +0300,
>>> Ozan Çağlayan wrote:
>>>   
>>>       
>>>> Takashi Iwai wrote:
>>>>     
>>>>         
>>>>> At Sun, 06 Jul 2008 19:18:01 +0300,
>>>>> Ozan Çağlayan wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Everything seems OK with those onboard audio chipsets but there's 
>>>>>> absolutely no sound.
>>>>>> We have 2 bug reports on our bug tracking system indicating this 
>>>>>> regression for MCP51, MCP61 and MCP73.
>>>>>>
>>>>>> Here are the URL's for alsa-info.sh output's:
>>>>>>
>>>>>> MCP51: http://pastebin.ca/1062418
>>>>>> MCP61: http://pastebin.ca/1058482
>>>>>> MCP73: http://pastebin.ca/1058319
>>>>>>
>>>>>> Those users have recently reported that downgrading to 1.0.16 series 
>>>>>> solves the problem.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Could you run alsa-info.sh on 1.0.16, too?  Then we can compare
>>>>> between working and non-working states.
>>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Takashi
>>>>>   
>>>>>       
>>>>>           
>>>> Hi,
>>>>
>>>> I've also entered a bug report for this problem which includes the two 
>>>> outputs:
>>>>
>>>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4038
>>>>     
>>>>         
>>> The first thing to check is that you are using pulse plugin.
>>> Is it intended, and confirmed to work?
>>>
>>> The next thing to check is whether 1.0.16 driver works with the same 
>>> environment (1.0.17 lib, utils, etc) -- that is, your 1.0.16 alsa-info
>>> output.  If yes, get alsa-info.sh output again, then install 1.0.17
>>> driver again and re-test.  Get alsa-info.sh output on 1.0.17 again
>>> (for non-working) to compare exactly.
>>>   
>>>       
>> First the problem is not present when pulseaudio is stopped. And also, 
>> we can get sound with 1.0.17rc1 too. So briefly:
>>
>> 1.0.16 + pulse -> works well
>> 1.0.17rc1 + pulse -> works well
>> 1.0.17rc1,rc2 + pulse -> No sound.
>>
>> It seems that something is broken for these chipsets in either alsa or 
>> pulse tree. Any ideas for your alsa-{driver,lib,plugins} part?
>>     
>
> Try to Compare alsa-info.sh outputs between these versions.
> If there is a significant difference in codec#* proc files, then
> something was changed in the driver side.  If not, it's pulse
> problem.
>   
It seems that we've found the problem.
MCP51 and MCP61 works well when the 1.0.17 introduced module parameter 
bdl_pos_adj is explicitly set to 0 when probing the snd-hda-intel module.

-- 

Ozan Çağlayan
<ozan_at_pardus.org.tr>

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Takashi Iwai]

At Thu, 10 Jul 2008 19:41:45 +0300,
Ozan Çağlayan wrote:
> 
> Takashi Iwai wrote:
> > At Tue, 08 Jul 2008 00:31:43 +0300,
> > Ozan Çağlayan wrote:
> >   
> >> Takashi Iwai wrote:
> >>     
> >>> At Sun, 06 Jul 2008 19:18:01 +0300,
> >>> Ozan Çağlayan wrote:
> >>>   
> >>>       
> >>>> Everything seems OK with those onboard audio chipsets but there's 
> >>>> absolutely no sound.
> >>>> We have 2 bug reports on our bug tracking system indicating this 
> >>>> regression for MCP51, MCP61 and MCP73.
> >>>>
> >>>> Here are the URL's for alsa-info.sh output's:
> >>>>
> >>>> MCP51: http://pastebin.ca/1062418
> >>>> MCP61: http://pastebin.ca/1058482
> >>>> MCP73: http://pastebin.ca/1058319
> >>>>
> >>>> Those users have recently reported that downgrading to 1.0.16 series 
> >>>> solves the problem.
> >>>>     
> >>>>         
> >>> Could you run alsa-info.sh on 1.0.16, too?  Then we can compare
> >>> between working and non-working states.
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>   
> >>>       
> >> Hi,
> >>
> >> I've also entered a bug report for this problem which includes the two 
> >> outputs:
> >>
> >> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4038
> >>     
> >
> > The first thing to check is that you are using pulse plugin.
> > Is it intended, and confirmed to work?
> >
> > The next thing to check is whether 1.0.16 driver works with the same 
> > environment (1.0.17 lib, utils, etc) -- that is, your 1.0.16 alsa-info
> > output.  If yes, get alsa-info.sh output again, then install 1.0.17
> > driver again and re-test.  Get alsa-info.sh output on 1.0.17 again
> > (for non-working) to compare exactly.
> >   
> First the problem is not present when pulseaudio is stopped. And also, 
> we can get sound with 1.0.17rc1 too. So briefly:
> 
> 1.0.16 + pulse -> works well
> 1.0.17rc1 + pulse -> works well
> 1.0.17rc1,rc2 + pulse -> No sound.
> 
> It seems that something is broken for these chipsets in either alsa or 
> pulse tree. Any ideas for your alsa-{driver,lib,plugins} part?

Try to Compare alsa-info.sh outputs between these versions.
If there is a significant difference in codec#* proc files, then
something was changed in the driver side.  If not, it's pulse
problem.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Ozan Çağlayan]

Takashi Iwai wrote On 11-07-2008 20:54:
>
> To make sure: bdl_pos_adj=32 or higher doesn't work, too?
> Also, if you set bdl_pos_adj=0, do you get any warning messages?
>
> It's fine to take bdl_pos_adj=0 as default for Nvidia chips.  But,
> basically this value (when it's big enough) shouldn't disable the
> sound at all.
>   
I've tried the values (2,8,16,32,64,128,256,1024,2048,4096,8192).
When the parameter is set to 2048,4096 or 8192, here's the dmesg message 
we get:

ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
bigger bdl_pos_adj.
ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096

The sound works well with those values.

The other small values avoid pulse to work correctly with ALSA.

When the parameter is set 0, the sound works well and the driver outputs 
this message:
hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
bigger bdl_pos_adj.

2 MCP51 and 2 MCP61 users reported that setting the parameter to 0 
solves the incompatibility between alsa and pulse.

Thanks.


-- 
Ozan Çağlayan


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Ozan Çağlayan]

Takashi Iwai wrote On 12-07-2008 00:25:
> At Fri, 11 Jul 2008 09:31:59 +0300,
> Ozan Çağlayan wrote:
>   
>> Takashi Iwai wrote On 11-07-2008 20:54:
>>     
>>> To make sure: bdl_pos_adj=32 or higher doesn't work, too?
>>> Also, if you set bdl_pos_adj=0, do you get any warning messages?
>>>
>>> It's fine to take bdl_pos_adj=0 as default for Nvidia chips.  But,
>>> basically this value (when it's big enough) shouldn't disable the
>>> sound at all.
>>>   
>>>       
>> I've tried the values (2,8,16,32,64,128,256,1024,2048,4096,8192).
>> When the parameter is set to 2048,4096 or 8192, here's the dmesg message 
>> we get:
>>
>> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
>> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
>> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
>> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
>> hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
>> bigger bdl_pos_adj.
>> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
>> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
>> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
>> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
>>
>> The sound works well with those values.
>>     
>
> It's because bdl_pos_adj=0 is taken as fallback.
>
>   
>> The other small values avoid pulse to work correctly with ALSA.
>>     
>
> What about other applications?  Could you run ALSA apps, e.g. aplay,
> without pulse?
>   
Yes. I can play an mp3 file with mplayer, using alsa output.
Without pulse everything was already fine..
>   
>> When the parameter is set 0, the sound works well and the driver outputs 
>> this message:
>> hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
>> bigger bdl_pos_adj.
>>     
>
> So, it means that the problem still exists.  The driver delays the
> call of snd_pcm_period_elapsed() with a busy loop.  The bdl_pos_adj
> adds a constant delay, OTOH.
>   
So If I resume a little bit what we have now:

- On a system which does not use pulseaudio, the chipset works with 
1.0.16 and all 1.0.16 RC's.
- On a system using pulseaudio, it's impossible to get sound when using 
1.0.17rc2 and 1.0.17rc3 if bdl_pos_adj is not explicitly set to 0. dmesg 
output contains also these two lines when the module is loaded:

ACPI: PCI Interrupt 0000:00:10.1[B] -> Link [AAZA] -> GSI 22 (level, 
low) -> IRQ 22
hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
bigger bdl_pos_adj.

-- 
Ozan Çağlayan


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Takashi Iwai]

At Fri, 11 Jul 2008 00:26:26 +0300,
Ozan Çağlayan wrote:
> 
> Takashi Iwai wrote:
> > At Thu, 10 Jul 2008 19:41:45 +0300,
> > Ozan Çağlayan wrote:
> >   
> >> Takashi Iwai wrote:
> >>     
> >>> At Tue, 08 Jul 2008 00:31:43 +0300,
> >>> Ozan Çağlayan wrote:
> >>>   
> >>>       
> >>>> Takashi Iwai wrote:
> >>>>     
> >>>>         
> >>>>> At Sun, 06 Jul 2008 19:18:01 +0300,
> >>>>> Ozan Çağlayan wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> Everything seems OK with those onboard audio chipsets but there's 
> >>>>>> absolutely no sound.
> >>>>>> We have 2 bug reports on our bug tracking system indicating this 
> >>>>>> regression for MCP51, MCP61 and MCP73.
> >>>>>>
> >>>>>> Here are the URL's for alsa-info.sh output's:
> >>>>>>
> >>>>>> MCP51: http://pastebin.ca/1062418
> >>>>>> MCP61: http://pastebin.ca/1058482
> >>>>>> MCP73: http://pastebin.ca/1058319
> >>>>>>
> >>>>>> Those users have recently reported that downgrading to 1.0.16 series 
> >>>>>> solves the problem.
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> Could you run alsa-info.sh on 1.0.16, too?  Then we can compare
> >>>>> between working and non-working states.
> >>>>>
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> Takashi
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> Hi,
> >>>>
> >>>> I've also entered a bug report for this problem which includes the two 
> >>>> outputs:
> >>>>
> >>>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4038
> >>>>     
> >>>>         
> >>> The first thing to check is that you are using pulse plugin.
> >>> Is it intended, and confirmed to work?
> >>>
> >>> The next thing to check is whether 1.0.16 driver works with the same 
> >>> environment (1.0.17 lib, utils, etc) -- that is, your 1.0.16 alsa-info
> >>> output.  If yes, get alsa-info.sh output again, then install 1.0.17
> >>> driver again and re-test.  Get alsa-info.sh output on 1.0.17 again
> >>> (for non-working) to compare exactly.
> >>>   
> >>>       
> >> First the problem is not present when pulseaudio is stopped. And also, 
> >> we can get sound with 1.0.17rc1 too. So briefly:
> >>
> >> 1.0.16 + pulse -> works well
> >> 1.0.17rc1 + pulse -> works well
> >> 1.0.17rc1,rc2 + pulse -> No sound.
> >>
> >> It seems that something is broken for these chipsets in either alsa or 
> >> pulse tree. Any ideas for your alsa-{driver,lib,plugins} part?
> >>     
> >
> > Try to Compare alsa-info.sh outputs between these versions.
> > If there is a significant difference in codec#* proc files, then
> > something was changed in the driver side.  If not, it's pulse
> > problem.
> >   
> It seems that we've found the problem.
> MCP51 and MCP61 works well when the 1.0.17 introduced module parameter 
> bdl_pos_adj is explicitly set to 0 when probing the snd-hda-intel module.

To make sure: bdl_pos_adj=32 or higher doesn't work, too?
Also, if you set bdl_pos_adj=0, do you get any warning messages?

It's fine to take bdl_pos_adj=0 as default for Nvidia chips.  But,
basically this value (when it's big enough) shouldn't disable the
sound at all.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Takashi Iwai]

At Fri, 11 Jul 2008 09:31:59 +0300,
Ozan Çağlayan wrote:
> 
> Takashi Iwai wrote On 11-07-2008 20:54:
> >
> > To make sure: bdl_pos_adj=32 or higher doesn't work, too?
> > Also, if you set bdl_pos_adj=0, do you get any warning messages?
> >
> > It's fine to take bdl_pos_adj=0 as default for Nvidia chips.  But,
> > basically this value (when it's big enough) shouldn't disable the
> > sound at all.
> >   
> I've tried the values (2,8,16,32,64,128,256,1024,2048,4096,8192).
> When the parameter is set to 2048,4096 or 8192, here's the dmesg message 
> we get:
> 
> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
> bigger bdl_pos_adj.
> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> 
> The sound works well with those values.

It's because bdl_pos_adj=0 is taken as fallback.

> The other small values avoid pulse to work correctly with ALSA.

What about other applications?  Could you run ALSA apps, e.g. aplay,
without pulse?

> When the parameter is set 0, the sound works well and the driver outputs 
> this message:
> hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
> bigger bdl_pos_adj.

So, it means that the problem still exists.  The driver delays the
call of snd_pcm_period_elapsed() with a busy loop.  The bdl_pos_adj
adds a constant delay, OTOH.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Hans-Frieder Vogt]

Just a few more things to add (maybe it gets clearer):
On a GeForce 8200 board (MCP78S), using the pcm example program from alsa-lib-1.0.17rc2/test,
kernel driver version 1.0.17rc3:
(ignoring my general sound distortion problem which I will address again in another post)

bdl_pos_adj=0
both devices "default" and "plughw:0,0" work, i.e. give continuous sound

bdl_pos_adj=1
bdl_pos_adj=2
bdl_pos_adj=8
no sound, pcm seems to gets stuck (example program does not return)

bdl_pos_adj=16
bdl_pos_adj=32
bdl_pos_adj=64
bdl_pos_adj=128
bdl_pos_adj=256
bdl_pos_adj=512
bdl_pos_adj=1024
bdl_pos_adj=2048
default device: works, i.e. sound
plughw:0,0: no sound, pcm gets stuck

bdl_pos_adj=4096
bdl_pos_adj=8192
ALSA /home/haef/Treiber/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
default device: works, i.e. sound
plughw:0,0: just one beep (approx. 0.5s of sound), then pcm gets stuck

Any ideas?

Am Freitag, 11. Juli 2008 schrieb Ozan Çağlayan:
> Takashi Iwai wrote On 12-07-2008 00:25:
> > At Fri, 11 Jul 2008 09:31:59 +0300,
> > Ozan Çağlayan wrote:
> >   
> >> Takashi Iwai wrote On 11-07-2008 20:54:
> >>     
> >>> To make sure: bdl_pos_adj=32 or higher doesn't work, too?
> >>> Also, if you set bdl_pos_adj=0, do you get any warning messages?
> >>>
> >>> It's fine to take bdl_pos_adj=0 as default for Nvidia chips.  But,
> >>> basically this value (when it's big enough) shouldn't disable the
> >>> sound at all.
> >>>   
> >>>       
> >> I've tried the values (2,8,16,32,64,128,256,1024,2048,4096,8192).
> >> When the parameter is set to 2048,4096 or 8192, here's the dmesg message 
> >> we get:
> >>
> >> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> >> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> >> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> >> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> >> hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
> >> bigger bdl_pos_adj.
> >> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> >> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> >> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> >> ALSA ../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> >>
> >> The sound works well with those values.
> >>     
> >
> > It's because bdl_pos_adj=0 is taken as fallback.
> >
> >   
> >> The other small values avoid pulse to work correctly with ALSA.
> >>     
> >
> > What about other applications?  Could you run ALSA apps, e.g. aplay,
> > without pulse?
> >   
> Yes. I can play an mp3 file with mplayer, using alsa output.
> Without pulse everything was already fine..
> >   
> >> When the parameter is set 0, the sound works well and the driver outputs 
> >> this message:
> >> hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
> >> bigger bdl_pos_adj.
> >>     
> >
> > So, it means that the problem still exists.  The driver delays the
> > call of snd_pcm_period_elapsed() with a busy loop.  The bdl_pos_adj
> > adds a constant delay, OTOH.
> >   
> So If I resume a little bit what we have now:
> 
> - On a system which does not use pulseaudio, the chipset works with 
> 1.0.16 and all 1.0.16 RC's.
> - On a system using pulseaudio, it's impossible to get sound when using 
> 1.0.17rc2 and 1.0.17rc3 if bdl_pos_adj is not explicitly set to 0. dmesg 
> output contains also these two lines when the module is loaded:
> 
> ACPI: PCI Interrupt 0000:00:10.1[B] -> Link [AAZA] -> GSI 22 (level, 
> low) -> IRQ 22
> hda-intel: IRQ timing workaround is activated for card #0. Suggest a 
> bigger bdl_pos_adj.
> 



-- 
--
Hans-Frieder Vogt                 e-mail: hfvogt <at> gmx .dot. net
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Takashi Iwai]

At Sun, 13 Jul 2008 08:45:55 +0200,
Hans-Frieder Vogt wrote:
> 
> Just a few more things to add (maybe it gets clearer):
> On a GeForce 8200 board (MCP78S), using the pcm example program from alsa-lib-1.0.17rc2/test,
> kernel driver version 1.0.17rc3:
> (ignoring my general sound distortion problem which I will address again in another post)
> 
> bdl_pos_adj=0
> both devices "default" and "plughw:0,0" work, i.e. give continuous sound
> 
> bdl_pos_adj=1
> bdl_pos_adj=2
> bdl_pos_adj=8
> no sound, pcm seems to gets stuck (example program does not return)
> 
> bdl_pos_adj=16
> bdl_pos_adj=32
> bdl_pos_adj=64
> bdl_pos_adj=128
> bdl_pos_adj=256
> bdl_pos_adj=512
> bdl_pos_adj=1024
> bdl_pos_adj=2048
> default device: works, i.e. sound
> plughw:0,0: no sound, pcm gets stuck
> 
> bdl_pos_adj=4096
> bdl_pos_adj=8192
> ALSA /home/haef/Treiber/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> default device: works, i.e. sound
> plughw:0,0: just one beep (approx. 0.5s of sound), then pcm gets stuck
> 
> Any ideas?

Thanks, that's really good to know.  Does this happen with aplay, too? 

Now you don't need to play so many bdl_pos_adj values any more.
Checking 1 and 32 should suffice.

Could you check /proc/asound/card0/pcm0p/sub0/* at non-working time
with bdl_pos_adj=32?

Also, try the patch below.  If my guess is right, the problem is
unaligned period size.


Takashi

---
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 16715a6..ef9f072 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1047,9 +1047,13 @@ static int azx_setup_periods(struct azx *chip,
 	pos_adj = bdl_pos_adj[chip->dev_index];
 	if (pos_adj > 0) {
 		struct snd_pcm_runtime *runtime = substream->runtime;
+		int pos_align = pos_adj;
 		pos_adj = (pos_adj * runtime->rate + 47999) / 48000;
 		if (!pos_adj)
-			pos_adj = 1;
+			pos_adj = pos_align;
+		else
+			pos_adj = ((pos_adj + pos_align - 1) / pos_align) *
+				pos_align;
 		pos_adj = frames_to_bytes(runtime, pos_adj);
 		if (pos_adj >= period_bytes) {
 			snd_printk(KERN_WARNING "Too big adjustment %d\n",

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Hans-Frieder Vogt]

Takashi,

with aplay things are a bit more differentiated:

bdl_pos_adj=0 and 1 are as described below

bdl_pos_adj=32
device "default" works
device "plughw:0,0" works or does not work, may be depending on the sound format. For a nonworking file, here is the output of the files /proc/asound/card0/pcm0p/sub0/*:
/proc/asound/card0/pcm0p/sub0/hw_params:
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 4096
buffer_size: 16384
/proc/asound/card0/pcm0p/sub0/info:
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: ALC883 Analog
name: ALC883 Analog
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
/proc/asound/card0/pcm0p/sub0/prealloc:
64
/proc/asound/card0/pcm0p/sub0/prealloc_max:
1024
/proc/asound/card0/pcm0p/sub0/status:
state: RUNNING
trigger_time: 2795.506618360
tstamp      : 2797.052537640
delay       : 16384
avail       : 0
avail_max   : 818
-----
hw_ptr      : 818
appl_ptr    : 17202
/proc/asound/card0/pcm0p/sub0/sw_params:
tstamp_mode: NONE
period_step: 1
avail_min: 4096
start_threshold: 16384
stop_threshold: 16384
silence_threshold: 0
silence_size: 0
boundary: 4611686018427387904

the same file played with mmap (aplay -D plughw:0,0 --mmap soundfile) also gives no sound. 
/proc/asound/card0/pcm0p/sub0/hw_params:
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 4096
buffer_size: 16384
/proc/asound/card0/pcm0p/sub0/info:
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: ALC883 Analog
name: ALC883 Analog
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
/proc/asound/card0/pcm0p/sub0/prealloc:
64
/proc/asound/card0/pcm0p/sub0/prealloc_max:
1024
/proc/asound/card0/pcm0p/sub0/status:
state: RUNNING
trigger_time: 2948.343350480
tstamp      : 2949.758334160
delay       : 16384
avail       : 0
avail_max   : 0
-----
hw_ptr      : 0
appl_ptr    : 16384
/proc/asound/card0/pcm0p/sub0/sw_params:
tstamp_mode: NONE
period_step: 1
avail_min: 4096
start_threshold: 16384
stop_threshold: 16384
silence_threshold: 0
silence_size: 0
boundary: 4611686018427387904

Your patch really solves this problem for bdl_pos_adj=32 (for bdl_pos_adj=0 and 1 unchanged). Thanks!

Cheers,
Hans-Frieder

Am Dienstag, 15. Juli 2008 schrieb Takashi Iwai:
> At Sun, 13 Jul 2008 08:45:55 +0200,
> Hans-Frieder Vogt wrote:
> > 
> > Just a few more things to add (maybe it gets clearer):
> > On a GeForce 8200 board (MCP78S), using the pcm example program from alsa-lib-1.0.17rc2/test,
> > kernel driver version 1.0.17rc3:
> > (ignoring my general sound distortion problem which I will address again in another post)
> > 
> > bdl_pos_adj=0
> > both devices "default" and "plughw:0,0" work, i.e. give continuous sound
> > 
> > bdl_pos_adj=1
> > bdl_pos_adj=2
> > bdl_pos_adj=8
> > no sound, pcm seems to gets stuck (example program does not return)
> > 
> > bdl_pos_adj=16
> > bdl_pos_adj=32
> > bdl_pos_adj=64
> > bdl_pos_adj=128
> > bdl_pos_adj=256
> > bdl_pos_adj=512
> > bdl_pos_adj=1024
> > bdl_pos_adj=2048
> > default device: works, i.e. sound
> > plughw:0,0: no sound, pcm gets stuck
> > 
> > bdl_pos_adj=4096
> > bdl_pos_adj=8192
> > ALSA /home/haef/Treiber/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1056: Too big adjustment 4096
> > default device: works, i.e. sound
> > plughw:0,0: just one beep (approx. 0.5s of sound), then pcm gets stuck
> > 
> > Any ideas?
> 
> Thanks, that's really good to know.  Does this happen with aplay, too? 
> 
> Now you don't need to play so many bdl_pos_adj values any more.
> Checking 1 and 32 should suffice.
> 
> Could you check /proc/asound/card0/pcm0p/sub0/* at non-working time
> with bdl_pos_adj=32?
> 
> Also, try the patch below.  If my guess is right, the problem is
> unaligned period size.
> 
> 
> Takashi
> 
> ---
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 16715a6..ef9f072 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1047,9 +1047,13 @@ static int azx_setup_periods(struct azx *chip,
>  	pos_adj = bdl_pos_adj[chip->dev_index];
>  	if (pos_adj > 0) {
>  		struct snd_pcm_runtime *runtime = substream->runtime;
> +		int pos_align = pos_adj;
>  		pos_adj = (pos_adj * runtime->rate + 47999) / 48000;
>  		if (!pos_adj)
> -			pos_adj = 1;
> +			pos_adj = pos_align;
> +		else
> +			pos_adj = ((pos_adj + pos_align - 1) / pos_align) *
> +				pos_align;
>  		pos_adj = frames_to_bytes(runtime, pos_adj);
>  		if (pos_adj >= period_bytes) {
>  			snd_printk(KERN_WARNING "Too big adjustment %d\n",
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
> 



-- 
--
Hans-Frieder Vogt                 e-mail: hfvogt <at> gmx .dot. net

Re: 1.0.16->1.0.17 regression for some HDA NVidia's

[Takashi Iwai]

At Tue, 15 Jul 2008 22:54:51 +0200,
Hans-Frieder Vogt wrote:
> 
> Takashi,
> 
> with aplay things are a bit more differentiated:
> 
> bdl_pos_adj=0 and 1 are as described below
> 
> bdl_pos_adj=32
> device "default" works
> device "plughw:0,0" works or does not work, may be depending on the sound format. For a nonworking file, here is the output of the files /proc/asound/card0/pcm0p/sub0/*:
> /proc/asound/card0/pcm0p/sub0/hw_params:
> access: RW_INTERLEAVED
> format: S16_LE
> subformat: STD
> channels: 2
> rate: 44100 (44100/1)
> period_size: 4096
> buffer_size: 16384
> /proc/asound/card0/pcm0p/sub0/info:
> card: 0
> device: 0
> subdevice: 0
> stream: PLAYBACK
> id: ALC883 Analog
> name: ALC883 Analog
> subname: subdevice #0
> class: 0
> subclass: 0
> subdevices_count: 1
> subdevices_avail: 0
> /proc/asound/card0/pcm0p/sub0/prealloc:
> 64
> /proc/asound/card0/pcm0p/sub0/prealloc_max:
> 1024
> /proc/asound/card0/pcm0p/sub0/status:
> state: RUNNING
> trigger_time: 2795.506618360
> tstamp      : 2797.052537640
> delay       : 16384
> avail       : 0
> avail_max   : 818
> -----
> hw_ptr      : 818
> appl_ptr    : 17202
> /proc/asound/card0/pcm0p/sub0/sw_params:
> tstamp_mode: NONE
> period_step: 1
> avail_min: 4096
> start_threshold: 16384
> stop_threshold: 16384
> silence_threshold: 0
> silence_size: 0
> boundary: 4611686018427387904
> 
> the same file played with mmap (aplay -D plughw:0,0 --mmap soundfile) also gives no sound. 
> /proc/asound/card0/pcm0p/sub0/hw_params:
> access: MMAP_INTERLEAVED
> format: S16_LE
> subformat: STD
> channels: 2
> rate: 44100 (44100/1)
> period_size: 4096
> buffer_size: 16384
> /proc/asound/card0/pcm0p/sub0/info:
> card: 0
> device: 0
> subdevice: 0
> stream: PLAYBACK
> id: ALC883 Analog
> name: ALC883 Analog
> subname: subdevice #0
> class: 0
> subclass: 0
> subdevices_count: 1
> subdevices_avail: 0
> /proc/asound/card0/pcm0p/sub0/prealloc:
> 64
> /proc/asound/card0/pcm0p/sub0/prealloc_max:
> 1024
> /proc/asound/card0/pcm0p/sub0/status:
> state: RUNNING
> trigger_time: 2948.343350480
> tstamp      : 2949.758334160
> delay       : 16384
> avail       : 0
> avail_max   : 0
> -----
> hw_ptr      : 0
> appl_ptr    : 16384
> /proc/asound/card0/pcm0p/sub0/sw_params:
> tstamp_mode: NONE
> period_step: 1
> avail_min: 4096
> start_threshold: 16384
> stop_threshold: 16384
> silence_threshold: 0
> silence_size: 0
> boundary: 4611686018427387904
> 
> Your patch really solves this problem for bdl_pos_adj=32 (for bdl_pos_adj=0 and 1 unchanged). Thanks!

Thanks for testing!  It's not bug that bdl_pos_adj=0 and 1 don't
change the behavior.  It's intentional.  ICH takes bdl_pos_adj=1,
and =0 means to disable the feature.


Takashi