On Wed, Apr 22, 2009 at 09:22:56PM +0000, Jacob Meuser wrote:
> On Wed, Apr 22, 2009 at 01:41:59PM +0200, LEVAI Daniel wrote:
> > On Tuesday 21 April 2009 14.37.55 Jacob Meuser wrote:
> > > On Tue, Apr 21, 2009 at 12:56:22PM +0200, LEVAI Daniel wrote:
> > > > Hi!
> > > >
> > > > I'm using this ThinkPad T60, and just realized that if using an
> > > > earphone,
> > > > the console's audible bell is blowing my ears off. I couldn't find
> > > > anything relevant in mixerctl -a output, nevertheless I've changed every
> > > > outputs control's volume to 0 to see which one could be it (no luck). Is
> > > > it possible to lower the system beep's volume, so my ears won't bleed by
> > > > tomorrow? :)
> > >
> > > hopefully this gets you 'beep' controls. please let me know.
> > >
> > > beep generators should be considered i/o endpoints, like pins and
> > > converters.
> >
> > I've applied your diff, and now I have a sel2 control which claims that its
> > source is 'beep'. However, I can not do anything with it; when muted and
> > zero
> > volume the beep still happens:
> >
> > inputs.sel2_source=beep
> > outputs.sel2_mute=on
> > outputs.sel2=0
> > inputs.mix2_source=sel2,dac,sel4,sel6,cd
>
> might work better if you remove beep sources. I mean:
>
> $ mixerctl inputs.mix2_source=dac,sel4,sel6,cd
bleh. that won't work on this particular mixer.
and the intel docs say, "When the beep generator is actively generating
a tone, its output drives all Pin Widgets which are currently defined
output pins in a method of the vendor's choice, either by switching the
pin to the beep signal or by mixing the tone into the currently playing
stream. This node is never listed on any other node's connection list.
The actual vendor-defined connection only persists while the Beep
Generator is actively generating a tone. This widget may contain an
optional amplifier."
the beep generator is what you are seeing as "beep". notice that this
codec (AD1981HD) violates the standard by listing the beep generator
in another node's connection list (inputs.sel2_source=beep). and it
appears that there's no control over the beep through azalia.
the intel docs continue, "This Beep Generator feature is independent of
any optional "PC Beep Pin" or "Analog Beep Pin" input which is intended
to receive and externally generated tone or sound. The presence of
such a beep input is not exposed to software, nor defined in this
specification. If used, this type of beep input would be connected
through the codec to output pins in a vendor defined way, but such a
connection may be maintained only while the Link reset (RST#) is
asserted."
interestingly, the codec's datasheet lists a "PC BEEP IN" at nid 16,
but the codec tells us nid 16 is:
azalia0: black16 wcap=400000
cap=20<INPUT>
[15/00] color=black device=other conn=none conntype=atapi
location=spec2 chassis=internal special=atapi
I guess that follows the spec, which says "The presence of such a beep
input is not exposed to software" :/ this is common though. on several
realtek codecs, the beep input is similarly obscured, but they are
controllable like any other input. remember, the behaviour is "vendor
defined". but anyway, there is again apparently no way for you to turn
this off through azalia because, well, it is turned off through azalia
but you still hear it.
so I guess you just have to use wsconsctl.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
