* 1.0.16->1.0.17 regression for some HDA NVidia's @ 2008-07-06 16:18 Ozan Çağlayan 2008-07-07 16:00 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Ozan Çağlayan @ 2008-07-06 16:18 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-06 16:18 1.0.16->1.0.17 regression for some HDA NVidia's Ozan Çağlayan @ 2008-07-07 16:00 ` Takashi Iwai 2008-07-07 21:31 ` Ozan Çağlayan 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-07-07 16:00 UTC (permalink / raw) To: Ozan Çağlayan; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-07 16:00 ` Takashi Iwai @ 2008-07-07 21:31 ` Ozan Çağlayan 2008-07-08 10:09 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Ozan Çağlayan @ 2008-07-07 21:31 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-07 21:31 ` Ozan Çağlayan @ 2008-07-08 10:09 ` Takashi Iwai 2008-07-10 16:41 ` Ozan Çağlayan 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-07-08 10:09 UTC (permalink / raw) To: Ozan Çağlayan; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-08 10:09 ` Takashi Iwai @ 2008-07-10 16:41 ` Ozan Çağlayan 2008-07-11 4:47 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Ozan Çağlayan @ 2008-07-10 16:41 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-10 16:41 ` Ozan Çağlayan @ 2008-07-11 4:47 ` Takashi Iwai 2008-07-10 21:26 ` Ozan Çağlayan 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-07-11 4:47 UTC (permalink / raw) To: Ozan Çağlayan; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-11 4:47 ` Takashi Iwai @ 2008-07-10 21:26 ` Ozan Çağlayan 2008-07-11 17:54 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Ozan Çağlayan @ 2008-07-10 21:26 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-10 21:26 ` Ozan Çağlayan @ 2008-07-11 17:54 ` Takashi Iwai 2008-07-11 6:31 ` Ozan Çağlayan 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-07-11 17:54 UTC (permalink / raw) To: Ozan Çağlayan; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-11 17:54 ` Takashi Iwai @ 2008-07-11 6:31 ` Ozan Çağlayan 2008-07-11 21:25 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Ozan Çağlayan @ 2008-07-11 6:31 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-11 6:31 ` Ozan Çağlayan @ 2008-07-11 21:25 ` Takashi Iwai 2008-07-11 11:31 ` Ozan Çağlayan 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-07-11 21:25 UTC (permalink / raw) To: Ozan Çağlayan; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-11 21:25 ` Takashi Iwai @ 2008-07-11 11:31 ` Ozan Çağlayan 2008-07-13 6:45 ` Hans-Frieder Vogt 0 siblings, 1 reply; 15+ messages in thread From: Ozan Çağlayan @ 2008-07-11 11:31 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-11 11:31 ` Ozan Çağlayan @ 2008-07-13 6:45 ` Hans-Frieder Vogt 2008-07-14 6:47 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Hans-Frieder Vogt @ 2008-07-13 6:45 UTC (permalink / raw) To: alsa-devel; +Cc: Takashi Iwai, ozan 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-13 6:45 ` Hans-Frieder Vogt @ 2008-07-14 6:47 ` Takashi Iwai 2008-07-15 20:54 ` Hans-Frieder Vogt 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-07-14 6:47 UTC (permalink / raw) To: hfvogt; +Cc: ozan, alsa-devel 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", ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-14 6:47 ` Takashi Iwai @ 2008-07-15 20:54 ` Hans-Frieder Vogt 2008-07-16 10:49 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Hans-Frieder Vogt @ 2008-07-15 20:54 UTC (permalink / raw) Cc: Takashi Iwai, ozan, alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1.0.16->1.0.17 regression for some HDA NVidia's 2008-07-15 20:54 ` Hans-Frieder Vogt @ 2008-07-16 10:49 ` Takashi Iwai 0 siblings, 0 replies; 15+ messages in thread From: Takashi Iwai @ 2008-07-16 10:49 UTC (permalink / raw) To: hfvogt; +Cc: ozan, alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2008-07-16 10:49 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-07-06 16:18 1.0.16->1.0.17 regression for some HDA NVidia's Ozan Çağlayan 2008-07-07 16:00 ` Takashi Iwai 2008-07-07 21:31 ` Ozan Çağlayan 2008-07-08 10:09 ` Takashi Iwai 2008-07-10 16:41 ` Ozan Çağlayan 2008-07-11 4:47 ` Takashi Iwai 2008-07-10 21:26 ` Ozan Çağlayan 2008-07-11 17:54 ` Takashi Iwai 2008-07-11 6:31 ` Ozan Çağlayan 2008-07-11 21:25 ` Takashi Iwai 2008-07-11 11:31 ` Ozan Çağlayan 2008-07-13 6:45 ` Hans-Frieder Vogt 2008-07-14 6:47 ` Takashi Iwai 2008-07-15 20:54 ` Hans-Frieder Vogt 2008-07-16 10:49 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.