[alsa-devel] 1.0.16->1.0.17 regression for some HDA NVidia's
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
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
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.
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.
thanks,
Takashi
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?
Thanks a lot.
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.
Takashi
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.
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
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.
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
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.
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.
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",
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 = 1;
pos_adj = pos_align;elsepos_adj = ((pos_adj + pos_align - 1) / pos_align) *pos_align;
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/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
participants (3)
-
Hans-Frieder Vogt -
Ozan Çağlayan -
Takashi Iwai