Re: mixerctl outputs.master.mute=on doesn't mute inputs.beep
Fri 5.Apr'13 at 23:32:30 + Ted Unangst On Fri, Apr 05, 2013 at 23:36, Zé Loff wrote: On Sat, Apr 06, 2013 at 12:17:03AM +0300, Ville Valkonen wrote: Hello, what says wsconsctl keyboard.bell.volume ? Have you tried to turn it to 0? That mutes it, thanks. It's not nearly as convenient as hitting the 'mute button', but I guess I can live with it. At least I won't get the stink-eye when working at the public library or the like... Although, I'm still left with a question: shouldn't mixerctl handle this? The pc speaker may or may not be wired up through your sound card. I had that problem with some older hardware I was using last year. -- James Griffin: jmz at kontrol.kode5.net jmzgriffin at gmail.com A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
mixerctl outputs.master.mute=on doesn't mute inputs.beep
Hi everyone The subject line pretty much sums it up... If I set outputs.master.mute to on (either with mixerctl or with the mute key on this ThinkPad), or set outputs.master=0,0, the beep is still audible, even if 'beep' is added to the outputs.master.slaves (which it isn't by default). Furthermore, setting inputs.beep to whatever has no effect, as the beep is always audible, and always at the same volume (which I guess is the cause of it not being muted). Incidentally, audioctl output_muted=0 doesn't mute the beep either... Is this expected behaviour? I am running amd64 -current #60 (Apr 2), Intel 3400 HD Audio, azalia, conexant codec. dmesg, audioctl and mixerctl appended FWIW Thanks in advance. dmesg OpenBSD 5.3-current (GENERIC.MP) #60: Tue Apr 2 18:53:53 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4062691328 (3874MB) avail mem = 3946835968 (3763MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version 6QET69WW (1.39 ) date 04/26/2012 bios0: LENOVO 3680WE9 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! BOOT SSDT TCPA SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.20 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 13 (EXP1) acpiprt3 at acpi0: bus -1 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 5 (EXP4) acpiprt6 at acpi0: bus 2 (EXP5) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4694 serial 545 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 1197 MHz: speeds: 2400, 2399, 2266, 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: apic 1 int 16 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured Intel 3400 KT rev 0x06 at pci0 dev 22 function 3 not configured em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address 00:26:2d:fb:7c:63 ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 3400 HD Audio rev 0x06: msi azalia0: codecs: Conexant/0x5069, Intel/0x2804, using Conexant/0x5069 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x06: msi
Re: mixerctl outputs.master.mute=on doesn't mute inputs.beep
Hello, what says wsconsctl keyboard.bell.volume ? Have you tried to turn it to 0? -- Sincerely, Ville Valkonen On 5 April 2013 15:07, Zé Loff zel...@zeloff.org wrote: Hi everyone The subject line pretty much sums it up... If I set outputs.master.mute to on (either with mixerctl or with the mute key on this ThinkPad), or set outputs.master=0,0, the beep is still audible, even if 'beep' is added to the outputs.master.slaves (which it isn't by default). Furthermore, setting inputs.beep to whatever has no effect, as the beep is always audible, and always at the same volume (which I guess is the cause of it not being muted). Incidentally, audioctl output_muted=0 doesn't mute the beep either... Is this expected behaviour? I am running amd64 -current #60 (Apr 2), Intel 3400 HD Audio, azalia, conexant codec. dmesg, audioctl and mixerctl appended FWIW Thanks in advance. dmesg OpenBSD 5.3-current (GENERIC.MP) #60: Tue Apr 2 18:53:53 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4062691328 (3874MB) avail mem = 3946835968 (3763MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version 6QET69WW (1.39 ) date 04/26/2012 bios0: LENOVO 3680WE9 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! BOOT SSDT TCPA SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.20 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF ,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF ,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF ,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF ,ITSC cpu3: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 13 (EXP1) acpiprt3 at acpi0: bus -1 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 5 (EXP4) acpiprt6 at acpi0: bus 2 (EXP5) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4694 serial 545 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 1197 MHz: speeds: 2400, 2399, 2266, 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: apic 1 int 16 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured Intel 3400 KT rev 0x06 at pci0 dev 22 function 3 not configured em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address 00:26:2d:fb:7c:63 ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: apic 1 int 23 usb0 at ehci0: USB revision 2.0
Re: mixerctl outputs.master.mute=on doesn't mute inputs.beep
On Sat, Apr 06, 2013 at 12:17:03AM +0300, Ville Valkonen wrote: Hello, what says wsconsctl keyboard.bell.volume ? Have you tried to turn it to 0? That mutes it, thanks. It's not nearly as convenient as hitting the 'mute button', but I guess I can live with it. At least I won't get the stink-eye when working at the public library or the like... Although, I'm still left with a question: shouldn't mixerctl handle this?
Re: mixerctl outputs.master.mute=on doesn't mute inputs.beep
On Fri, Apr 05, 2013 at 23:36, Zé Loff wrote: On Sat, Apr 06, 2013 at 12:17:03AM +0300, Ville Valkonen wrote: Hello, what says wsconsctl keyboard.bell.volume ? Have you tried to turn it to 0? That mutes it, thanks. It's not nearly as convenient as hitting the 'mute button', but I guess I can live with it. At least I won't get the stink-eye when working at the public library or the like... Although, I'm still left with a question: shouldn't mixerctl handle this? The pc speaker may or may not be wired up through your sound card.
Re: mixerctl outputs.master.mute=on doesn't mute inputs.beep
On Fri, Apr 05, 2013 at 11:32:30PM +, Ted Unangst wrote: On Fri, Apr 05, 2013 at 23:36, Zé Loff wrote: On Sat, Apr 06, 2013 at 12:17:03AM +0300, Ville Valkonen wrote: Hello, what says wsconsctl keyboard.bell.volume ? Have you tried to turn it to 0? That mutes it, thanks. It's not nearly as convenient as hitting the 'mute button', but I guess I can live with it. At least I won't get the stink-eye when working at the public library or the like... Although, I'm still left with a question: shouldn't mixerctl handle this? The pc speaker may or may not be wired up through your sound card. It happens with headphones too... Or do you mean that in some cases the preamp is completely bypassed (honest question)? --
Re: mixerctl outputs.master.mute=on doesn't mute inputs.beep
On Sat, Apr 06, 2013 at 01:39, Zé Loff wrote: The pc speaker may or may not be wired up through your sound card. It happens with headphones too... Or do you mean that in some cases the preamp is completely bypassed (honest question)? it's complicated. :) From what I've seen, I think on some machines the beep device is connected both to the builtin speaker *and* to the sound card. Then Windows or whatever will mute the speaker (ie, keyboard.bell=0) but enable it (or fake it) via the sound card. Then again, I don't think Windows makes many PC speaker noises these days. I've used machines (from various eras) where I could not stop the builtin speaker from beeping and others where I could not get it to beep, with/and/or/despite whatever the sound card was doing. :) I agree it might be nice if mixerctl worked on the pc speaker, but I am not at all surprised that it doesn't. FWIW, I just tested on my Thinkpad X201s. mixerctl works with the beep using outputs.master and without trying to mess with any of the other settings. But I always run with keyboard.bell=0 normally. However, there are oddities. mixerctl says spkr_source=dac-2:3, but if I change outputs.master.slaves to just that, nothing changes. If I change slaves to just dac-0:1, then outputs.master controls the volume of both music and beeps. The hardware mute button doesn't work for headphones, but does work for the speakers. Actually, it's stranger. The mute button mutes the beep with headphones, but not music. It mutes both when going through the speaker. However the beep is attached to this system, it is not as simple as a single dac input. I don't think there's an easy answer here, because I don't think there's universal agreement about what the desired behavior is, and then there's a huge variation in hardware on top of that, so it's hard to say if or where any bugs may be.
