Description of problem: Based on the information in bug 503791, the beep is now generated using ALSA and the soundcard instead of the PC speaker. Among other things, this means that "xset b" can no longer be used to control the pitch or duration of the beep. I actually find the new behavior objectionable....I have speakers that go into power saver mode, and I lose the first 1.5 seconds or so of any audio. So any time a beep would occur after a gap with no audio, it would wake up the speakers and I wouldn't hear the beep anyway. I would much prefer the beep to use the PC speaker as it has since the days of hamster-powered computers. Is there a way to configure my system to use the old style beep? If not, is there a way to configure the pitch and duration of the beep? Or to have it play an audio file of my choice? I can certainly create an audio file of the correct frequency and duration of my choice of beep. Version-Release number of selected component (if applicable): kernel version kernel-2.6.18-164.2.1.el5, platform x86_64 How reproducible: always Steps to Reproduce: 1. make a beep. Hit ctrl-G in emacs or xterm, for example 2. run xset b 20 2068 120 3. make another beep. Expect a nice, high-pitched beep like beeps used to sound back in the good old days before spam, html email, and composite window managers. The grass was greener back then, too. I remember. :-) Actual results: observe that the beep comes through the speakers connected to the sound card rather than the system's speaker and that xset b has no impact on the sound of the beep Expected results: Well, I don't really care that much of xset b works....it seems as the responsibility for making the beep has moved. But there should be *some* way to control the beep (this is Linux, after all), and it would be nice to avoid having to wake up the sound card and speakers just to make a little beep. I use emacs. I make a lot of beeps. Additional info: Just ran yum update to get to RHEL 5.4 today...hadn't run it in a few weeks.
The "xset b" command should work. The frequency is handled in the HDA driver and duration is handled in the drivers/char/keyboard.c . Could you try this test on your system? TERM="linux" setterm -bfreq 1600 -blength 800 > /dev/console < /dev/console echo -e "\a" Unfortunately, it seems that beep is generated only on last registered device according to keyboard.c - routine kd_mksound() - look for break in the list_for_each_prev() loop. I will try to make usage of HDA Beep functionality optional in 5.5.
The above commands run with no errors but have no effect. However, I notice the bell pitch sounded by gdm upon restart is different, so something somewhere is able to successfully change the pitch. I'll try to look into it a little more and see if I can figure out what's breaking down. I can also create a generic local account on my system and run that. Unfortunately, I can't chvt to a non-X virtual terminal...for whatever reason, with my video card and drivers, I get a blank screen when I do that. I hadn't actually noticed that until now. I am running with radeonhd drivers I compiled myself, so there's no additional bug to report at this time..... I'll post more information if/when I have it.
Although I can't see what I'm typing on a text virtual console, I can still type the commands and get beeps. I can also have something in my X environment generate a beep while my current VC is not the one with the X display. Results: setterm -bfreq n does in fact change the pitch of the beep, but not to the frequency specified. The actual frequency is inversely related to the number, and pitches are set to discrete blocks. For example, setterm -bfreq n for n in the inclusive range of 1313 to 1359 sets the bell pitch to 440 Hz. 1360 sets the pitch to approximately 415 Hz, half a tone lower than 440 Hz. 2700 sets the pitch to 220. These are the pitches generated by running echo -e "\a" (or, actually, print "\a" from perl) on the VC. Doing echo -e "\a" > /dev/console generates still a different pitch and duration.
Also, beeps generated from X keep the same pitch and duration even as setterm changes the frequency of the beeps on the text vc. If I run a script that beeps on the console, those beep pitches remain fixed regardless of whether X is running on my current VC. None of this is unexpected...I'm just confirming that which VC is current has no impact on the pitch. The only thing that impacts it is where the \a is sent.
Okay, the deal is that xset b DOES change the pitch, but it doesn't set it to the actual specified frequency. It behaves just like what I described above. So by beep command, xset b 20 2068 120, sets the beep pitch to approximately 280 Hz. Given the discrete bell pitches, the closest I can get to my desired frequency (which is close enough) is xset b 20 328 120 which sets the pitch to 2400 Hz.
adjusting bug title
The latest ALSA HDA driver for RHEL 5.5 is available here: http://people.redhat.com/~jkysela/RHEL5/ Please, report back test results. The HDA Beep can be completely disabled with "Beep" mute in alsamixer or any ALSA-aware mixer application in this update (Beep will be generated using internal PC speaker as in previous RHEL releases).
Confirmed on both counts. When I boot with the x86_64 kernel you made available (171), with HDA beep enabled, I get a pitch from among the available discrete frequency choices that is close to the requested frequency. With beep muted in alsamixer, the beep reverts to the PC speaker and is the exact pitch as expected based on the beep frequency. Thanks!
Marking as duplicate of parent bug#525390 . Please, re-open this bug in case of any related issues with future RHEL 5.5 kernels. *** This bug has been marked as a duplicate of bug 525390 ***
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
From #rhel5.5 channel: <lwang> sly 526751 is part of the bug 525390. so that one will move to ON_QA and put in the advisory Changed status to MODIFIED in preparation to add to kernel advisory.
Followed the steps in initial comment and the pitch of the beep changed. With no speakers/headphones plugged in (on a laptop) the sound comes from the internal speaker. If I plug in headphones, beep, with the correct pitch, comes through the headphones. Is this is what is expected? BTW, I have no Beep contol in alsamixer. Sound device is ICH9 (8086:293e) with Conexant CX20561 codec.
(In reply to comment #15) > Followed the steps in initial comment and the pitch of the beep changed. With > no speakers/headphones plugged in (on a laptop) the sound comes from the > internal speaker. If I plug in headphones, beep, with the correct pitch, comes > through the headphones. Is this is what is expected? BTW, I have no Beep > contol in alsamixer. Sound device is ICH9 (8086:293e) with Conexant CX20561 > codec. Unfortunately, this hardware (Conexant CS20561) does not have the digital HDA beep widget, so this issue cannot be tested with it. The described behaviour is correct.
Thanks Jaroslav for comment #16.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0178.html