# ThinkPad R61, console/terminal bell/beep, snd_hda



## jbhappy (Dec 28, 2009)

I have a Lenovo ThinkPad R61 that loses the "system beep" when the audio driver attaches to the hardware. If I remove "snd_hda_load=YES" from loader.conf and boot up, I get beeps if I generate a terminal bell on the console or in an xterm, and plugging/unplugging the AC adapter also produces the familiar ThinkPad battery chime.

Once I load snd_hda, all of this goes away (only at snd_hda, not when loading sound.ko by itself before snd_hda). Unloading the sound/snd_hda modules does not bring it back. I've loaded acpi_ibm.ko and have tried changing dev.acpi_ibm.0.volume around, and I've maxed all the mixer channels--neither helped, not that I really expected them to. I'm running 8-STABLE now, and this has been happening since I first installed FreeBSD on it, 7.0-REL/-STABLE.

Any suggestions? Have I missed anything obvious or even not-so-obvious?

thanks,
Jeff


----------



## mav@ (Dec 29, 2009)

Different HDA codecs have very different implementations of "system beep" pass-through. With some codecs snd_hda provides "speaker" mixer control. It is working fine with my Realtek. Some AD's could be problematic. For real investigation you should boot system with verbose messages enabled to get full debug information.


----------



## jbhappy (Dec 29, 2009)

mav@ said:
			
		

> Different HDA codecs have very different implementations of "system beep" pass-through. With some codecs snd_hda provides "speaker" mixer control.



I have a 'speaker' control, but turning it all the way up doesn't seem to have any effect. It does appear that there is a relationship between the system beep and the 'speaker' control on this laptop, though, if I understand the 'boot -v' output.



> For real investigation you should boot system with verbose messages enabled to get full debug information.



OK, I've done a 'boot -v' and attached the lines beginning with 'hdac' and 'pcm'. Full output is at http://web.mr-happy.com/mlf/bootv-thinkpad-8.0.txt if you need more.

/usr/sbin/mixer says:

```
Mixer vol      is currently set to 100:100
Mixer pcm      is currently set to 100:100
Mixer speaker  is currently set to 100:100
Mixer line     is currently set to 100:100
Mixer mic      is currently set to 100:100
Mixer mix      is currently set to 100:100
Mixer rec      is currently set to 100:100
Mixer ogain    is currently set to 100:100
Mixer monitor  is currently set to 100:100
Recording source: mic
```

thanks,
Jeff


----------



## mav@ (Dec 30, 2009)

This driver was not specially tuned for Connexant codecs, as I neither have one of them, nor datasheets for them. They are working just because driver has enough auto detect intelligence.
This codec can be configured in two different ways, and driver prefers bit simpler one with direct unmixed playback, luckily the one it can handle better. May be "system beep" needs another mode. Try to record from "mix" source, may be you'll find your beeps there. Also you may try this patch. It should switch codec into second mode, but I am not sure it will be better.

```
--- hdac.c      2009-12-06 02:15:38.000000000 +0200
+++ hdac.c.venice       2009-12-30 02:13:06.000000000 +0200
@@ -4866,6 +4866,22 @@ hdac_vendor_patch_parse(struct hdac_devi
                if (w != NULL)
                        w->enable = 0;
                break;
+       case HDA_CODEC_CX20549:
+               /*
+                * This codec has several possible usages, but none
+                * fit the parser best. Help parser to choose better.
+                */
+               /* Disable direct unmixed playback. */
+               w = hdac_widget_get(devinfo, 16);
+               if (w != NULL)
+                       w->connsenable[0] = 0;
+               w = hdac_widget_get(devinfo, 17);
+               if (w != NULL)
+                       w->connsenable[0] = 0;
+               w = hdac_widget_get(devinfo, 18);
+               if (w != NULL)
+                       w->connsenable[0] = 0;
+               break;
        }
 }
```


----------



## jbhappy (Dec 30, 2009)

mav@ said:
			
		

> Try to record from "mix" source, may be you'll find your beeps there.
> 
> [...]
> 
> Also you may try this patch. It should switch codec into second mode, but I am not sure it will be better.



No luck with either. The main changes I noticed are a slight hiss coming from the speaker when both the volume and PCM controls are maxed and the disappearance of several other controls:


```
Mixer vol      is currently set to 100:100
Mixer pcm      is currently set to 100:100
Mixer speaker  is currently set to 100:100
Mixer ogain    is currently set to  50:50
Recording source: mic
```

I've also grepped again for ^(hda|pcm) in dmesg output (from another 'boot -v') and attached it to this post in case it's useful.

Would it be better for me to take this up on one of the mailing lists, like multimedia or stable? Or file a PR?

One more semi-related question: is there a good way to rebuild a single kernel module, or do I need to rebuild the entire kernel (as I did to incorporate this patch)?

thanks,
Jeff


----------



## mav@ (Dec 30, 2009)

Hiss may mean that some additional signal have passed through, but if beep still doesn't - I have no idea where to look for it without datasheet.

Sure you can post somewhere else, but I don't expect it will help much, as mostly I am this driver's maintainer.

To build single module you can go to /usr/src/sys/modules/... and build there. But it is a bit hacky and IMHO may not pass to module your kernel options.


----------



## jbhappy (Dec 30, 2009)

mav@ said:
			
		

> Hiss may mean that some additional signal have passed through, but if beep still doesn't - I have no idea where to look for it without datasheet.
> 
> Sure you can post somewhere else, but I don't expect it will help much, as mostly I am this driver's maintainer.



OK, I guess I'll just let it slide then. Thank you for your assistance.

Jeff


----------



## ohauer (Dec 30, 2009)

do you see a difference with
`# sysctl hw.syscons.bell=0`


----------



## jbhappy (Dec 31, 2009)

No difference in an xterm or on a console vty whether it's 1 or 0.


----------



## indiocolifa (Jan 25, 2010)

*I fixed my beeps*



			
				jbhappy said:
			
		

> No difference in an xterm or on a console vty whether it's 1 or 0.



I fixed my beep (Thinkpad R61i) using on loader.conf:


```
acpi_ibm_load="YES"
```

Hope that helps.


----------



## climby (Sep 30, 2010)

can I make this permanent ?


----------



## climby (Sep 30, 2010)

I ment this : sysctl hw.syscons.bell=0


----------



## climby (Sep 30, 2010)

founded on other site and worked:

`# echo "hw.syscons.bell=0" >> /etc/sysctl.conf`


----------



## aparasch (Dec 3, 2010)

Is it possible the bell is a different device altogether, that needs its own driver? I have a VAIO AR270 running 8.1 release and I have the same bell problem described above. 

Another computer I have has a piezoelectric component that just beeps, have no idea what's in the VAIO.


----------



## aparasch (Dec 3, 2010)

I have the additional problem that when I do not load HDA the bell works in the shell when I log in, but not within KDE. I can settle for just the bell instead of sound, if I can make it work within KDE. Any thoughts how to fix that?


----------



## DutchDaemon (Dec 4, 2010)

Don't introduce new or unrelated problems in existing topics. Open a new one.


----------

