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