Re: explicit commandline control of speakers vs headphone output

Re: explicit commandline control of speakers vs headphone output

[Eric Holstege]

Thanks, Clemens. Here it is:

Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 31
  Mono: Playback 19 [61%] [-18.00dB] [on]
Simple mixer control 'Headphone',0
  Capabilities: pswitch penum
  Playback channels: Front Left - Front Right
  Mono:
  Front Left: Playback [on]
  Front Right: Playback [on]
Simple mixer control 'Speaker',0
  Capabilities: pswitch penum
  Playback channels: Front Left - Front Right
  Mono:
  Front Left: Playback [on]
  Front Right: Playback [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 253 [99%] [0.40dB]
  Front Right: Playback 253 [99%] [0.40dB]
Simple mixer control 'Front',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [0.00dB] [on]
  Front Right: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'Surround',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [0.00dB] [on]
  Front Right: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'Center',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 31
  Mono: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'LFE',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 31
  Mono: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'Line',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'CD',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 25 [81%] [3.00dB] [on]
  Front Right: Playback 25 [81%] [3.00dB] [on]
Simple mixer control 'Mic',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Mic Boost',0
  Capabilities: volume penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 3
  Front Left: 0 [0%]
  Front Right: 0 [0%]
Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'IEC958 Default PCM',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Beep',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 31
  Front Left: Capture 25 [81%] [21.00dB] [on]
  Front Right: Capture 25 [81%] [21.00dB] [on]
Simple mixer control 'Capture',1
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 31
  Front Left: Capture 0 [0%] [-16.50dB] [on]
  Front Right: Capture 0 [0%] [-16.50dB] [on]
Simple mixer control 'Channel Mode',0
  Capabilities: enum
  Items: '2ch' '4ch' '6ch'
  Item0: '2ch'
Simple mixer control 'Input Source',0
  Capabilities: cenum
  Items: 'Mic' 'Front Mic' 'Line' 'CD'
  Item0: 'Mic'
Simple mixer control 'Input Source',1
  Capabilities: cenum
  Items: 'Mic' 'Front Mic' 'Line' 'CD'
  Item0: 'Mic'

Regards
-Eric

Clemens Ladisch wrote:
> Eric Holstege wrote:
>   
>> My specific sound HW is "nVidia Corporation MCP79 High Definition Audio 
>> (rev b1)"
>>     
>
> This is the HDA controller, which can be combined with any HDA codec,
> which actually controls mixing.
>
> Please show the output of "amixer scontents".
>
>
> Regards,
> Clemens
>
>
>   

Re: explicit commandline control of speakers vs headphone output

[Clemens Ladisch]

Eric Holstege wrote:
> Simple mixer control ...

It looks as if your codec cannot be configured to disable the automatic
headphone switching.


Regards,
Clemens

Re: explicit commandline control of speakers vs headphone output

[Eric Holstege]

Thanks for the info. (FYI, I have a Windtop 2200 All-in-one touchscreen, 
on which I'm building an appliance with, among other things, VOIP phone 
and answering machine capability).  I want the user to be able to "put 
the call on speaker" even if the mic/headphone handset is plugged in.

Can amixer override this automuting. Is it that the driver just sets the 
speakers to mute *at the time* the headphone is plugged in, or does it 
force them mute *so long as* the headphone is plugged in?

Or, regarding the pin_configs possibility, I guess I somehow edit
/sys/devices/pci0000:00/0000:00:08.0/sound/card0/hwC0D0/init_pin_configs
(or maybe user_pin_configs?).   Could one point me to documentation on 
what the bits mean? Mine are:
0x11 0x411111f0
0x12 0x411111f0
0x14 0x01014010
0x15 0x411111f0
0x16 0x99130120
0x17 0x411111f0
0x18 0x01a19850
0x19 0x99a3095f
0x1a 0x411111f0
0x1b 0x99130130
0x1c 0x411111f0
0x1d 0x4004022b
0x1e 0x01451140
0x1f 0x411111f0


Regards
-Eric

David Henningsson wrote:
> 2010-08-27 20:46, Eric Holstege skrev:
>   
>> Thanks, Clemens;
>>
>> How were you able to determine that from the "amixer scontents" output.
>>
>> Although I can't disable *automatic* speaker mute on headphone 
>> insertion, can I explicitly unmute them again (e.g. with amixer sset or 
>> cset)?
>>
>> If not....
>> "cat /proc/asound/card*/codec*" says it is the Realtek ALC888.
>> Does this mean I have to somehow patch the kernel sound module file
>> .../linux-source-2.6.*/sound/pci/hda/patch_realtek.c
>> to fix this somehow?
>>     
>
> So in the long run, I think it would be better to leave all auto-muting
> to userspace. Then stuff like pulseaudio could to advanced decision of
> how to handle input events. But that's the long way.
>
> There are certainly ways to disable auto-muting for Realtek ALC888, look
> along the lines of "speaker_automute" and "unsol_event". It is also
> possible that you could tweak your user_pin_config to trick your HP out
> into a Line Out. That way it won't automute, and you don't have to
> recompile your kernel.
>
> As a side note: The VIA HDA driver, I believe, have an option for
> turning automute off. But it also sets "mute" on a misnamed control at
> the same time, tricking PA into believing that you want to mute all
> output. So PA is "helpful" and mutes everything else as well. :-/
>
>   

Re: explicit commandline control of speakers vs headphone output

[Eric Holstege]

Thanks, Clemens;

How were you able to determine that from the "amixer scontents" output.

Although I can't disable *automatic* speaker mute on headphone 
insertion, can I explicitly unmute them again (e.g. with amixer sset or 
cset)?

If not....
"cat /proc/asound/card*/codec*" says it is the Realtek ALC888.
Does this mean I have to somehow patch the kernel sound module file
.../linux-source-2.6.*/sound/pci/hda/patch_realtek.c
to fix this somehow?

Regards
-Eric


Clemens Ladisch wrote:
> Eric Holstege wrote:
>   
>> Simple mixer control ...
>>     
>
> It looks as if your codec cannot be configured to disable the automatic
> headphone switching.
>
>
> Regards,
> Clemens
>
>
>   

Re: explicit commandline control of speakers vs headphone output

[David Henningsson]

2010-08-27 20:46, Eric Holstege skrev:
> Thanks, Clemens;
> 
> How were you able to determine that from the "amixer scontents" output.
> 
> Although I can't disable *automatic* speaker mute on headphone 
> insertion, can I explicitly unmute them again (e.g. with amixer sset or 
> cset)?
> 
> If not....
> "cat /proc/asound/card*/codec*" says it is the Realtek ALC888.
> Does this mean I have to somehow patch the kernel sound module file
> .../linux-source-2.6.*/sound/pci/hda/patch_realtek.c
> to fix this somehow?

So in the long run, I think it would be better to leave all auto-muting
to userspace. Then stuff like pulseaudio could to advanced decision of
how to handle input events. But that's the long way.

There are certainly ways to disable auto-muting for Realtek ALC888, look
along the lines of "speaker_automute" and "unsol_event". It is also
possible that you could tweak your user_pin_config to trick your HP out
into a Line Out. That way it won't automute, and you don't have to
recompile your kernel.

As a side note: The VIA HDA driver, I believe, have an option for
turning automute off. But it also sets "mute" on a misnamed control at
the same time, tricking PA into believing that you want to mute all
output. So PA is "helpful" and mutes everything else as well. :-/

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: explicit commandline control of speakers vs headphone output

[Raymond Yau]

2010/8/28 David Henningsson <david.henningsson@canonical.com>

> 2010-08-27 20:46, Eric Holstege skrev:
> > Thanks, Clemens;
> >
> > How were you able to determine that from the "amixer scontents" output.
> >
> > Although I can't disable *automatic* speaker mute on headphone
> > insertion, can I explicitly unmute them again (e.g. with amixer sset or
> > cset)?
> >
> > If not....
> > "cat /proc/asound/card*/codec*" says it is the Realtek ALC888.
> > Does this mean I have to somehow patch the kernel sound module file
> > .../linux-source-2.6.*/sound/pci/hda/patch_realtek.c
> > to fix this somehow?
>
> So in the long run, I think it would be better to leave all auto-muting
> to userspace. Then stuff like pulseaudio could to advanced decision of
> how to handle input events. But that's the long way.
>
> There are certainly ways to disable auto-muting for Realtek ALC888, look
> along the lines of "speaker_automute" and "unsol_event". It is also
> possible that you could tweak your user_pin_config to trick your HP out
> into a Line Out. That way it won't automute, and you don't have to
> recompile your kernel.
>
> As a side note: The VIA HDA driver, I believe, have an option for
> turning automute off. But it also sets "mute" on a misnamed control at
> the same time, tricking PA into believing that you want to mute all
> output. So PA is "helpful" and mutes everything else as well. :-/
>
>
Some of the VIA codec allow independent headphone and the extra DAC and ADC
(i.e. subdevice 1)  can only be connected to headphone  and mic .at front
panel

the current implementation of the driver is buggy , since the sudevice 0
support multi channels but sudevice 1 only support 2 channels

Re: explicit commandline control of speakers vs headphone output

[Raymond Yau]

2010/8/28 Eric Holstege <eric_holstege@yahoo.com>

> Thanks, Clemens;
>
> How were you able to determine that from the "amixer scontents" output.
>
> Although I can't disable *automatic* speaker mute on headphone
> insertion, can I explicitly unmute them again (e.g. with amixer sset or
> cset)?
>
> If not....
> "cat /proc/asound/card*/codec*" says it is the Realtek ALC888.
> Does this mean I have to somehow patch the kernel sound module file
> .../linux-source-2.6.*/sound/pci/hda/patch_realtek.c
> to fix this somehow?
>

Post output of alsa-info.sh after a cold boot to allow BIOS setup the pins

ALC888 has 5 DAC and 2 ADC , if you want to implement a new model which
allow internal mic and  internal  speaker , mic jack and headphone jack to
be used independently by two applications  , you will need to disable the
automute function

Re: explicit commandline control of speakers vs headphone output

[Eric Holstege]

My specific sound HW is "nVidia Corporation MCP79 High Definition Audio 
(rev b1)"
*== lspci*:
00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio 
(rev b1)
        Subsystem: Micro-Star International Co., Ltd. Device 4570
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
        Memory at fae78000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel
*== lshal*:
udi = '/org/freedesktop/Hal/devices/pci_10de_ac0'
  info.linux.driver = '*HDA Intel*'  (string)
  info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
  info.product = 'MCP79 High Definition Audio'  (string)
  info.subsystem = 'pci'  (string)
  info.udi = '/org/freedesktop/Hal/devices/pci_10de_ac0'  (string)
  info.vendor = 'nVidia Corporation'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'pci'  (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:08.0'  (string)
  pci.device_class = 4  (0x4)  (int)
  pci.device_protocol = 0  (0x0)  (int)
  pci.device_subclass = 3  (0x3)  (int)
  pci.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:08.0'  (string)
  pci.product = '*MCP79 High Definition Audio*'  (string)
  pci.product_id = 2752  (*0xac0*)  (int)
  pci.subsys_product_id = 17776  (0x4570)  (int)
  pci.subsys_vendor = 'Micro-Star International Co., Ltd.'  (string)
  pci.subsys_vendor_id = 5218  (0x1462)  (int)
  pci.vendor = 'nVidia Corporation'  (string)
  pci.vendor_id = 4318  (0x10de)  (int)

Does the hardware support this (explicit control (e.g. via a script or 
commandline) of whether the sound  is going to the speakers or to the 
headphone even when the headphone is plugged in.)

If the hardware supports it, how would I, in fact, switch via 
commandline between the two outputs?
Thanks in advance
-Eric

-----------------------

Eric Holstege wrote:
> It appears that when I have a headphone plugged in, the speakers are 
> automatically disabled and the output sound is sent to the headphone.
>
> However, I want to explicitly control (e.g. via a script or 
> commandline - not a GUI) whether the sound from an (arbitrary) 
> application is going to the speakers or to the headphone even when the 
> headphone is plugged in.
> (When I say "arbitrary application" that means I can't alter the code 
> of the application itself).
>
> Is this possible?
>
> (I have heard that ALSA mutes the speakers when it detects plugged-in 
> headphones. Is switching between them as simple as using e.g. 
> amixer(1) to unmute the speakers and mute the headphones and vice 
> versa, or is there more to it.)
>

Re: explicit commandline control of speakers vs headphone output

[Clemens Ladisch]

Eric Holstege wrote:
> My specific sound HW is "nVidia Corporation MCP79 High Definition Audio 
> (rev b1)"

This is the HDA controller, which can be combined with any HDA codec,
which actually controls mixing.

Please show the output of "amixer scontents".


Regards,
Clemens

explicit commandline control of speakers vs headphone output

[Eric Holstege]

It appears that when I have a headphone plugged in, the speakers are 
automatically disabled and the output sound is sent to the headphone.

However, I want to explicitly control (e.g. via a script or commandline 
- not a GUI) whether the sound from an (arbitrary) application is going 
to the speakers or to the headphone even when the headphone is plugged in.
(When I say "arbitrary application" that means I can't alter the code of 
the application itself).

Is this possible?

(I have heard that ALSA mutes the speakers when it detects plugged-in 
headphones. Is switching between them as simple as using e.g. amixer(1) 
to unmute the speakers and mute the headphones and vice versa, or is 
there more to it.)

Re: explicit commandline control of speakers vs headphone output

[Raymond Yau]

2010/8/26 Eric Holstege <eric_holstege@yahoo.com>

> It appears that when I have a headphone plugged in, the speakers are
> automatically disabled and the output sound is sent to the headphone.
>
> However, I want to explicitly control (e.g. via a script or commandline
> - not a GUI) whether the sound from an (arbitrary) application is going
> to the speakers or to the headphone even when the headphone is plugged in.
> (When I say "arbitrary application" that means I can't alter the code of
> the application itself).
>
> Is this possible?
>
> (I have heard that ALSA mutes the speakers when it detects plugged-in
> headphones. Is switching between them as simple as using e.g. amixer(1)
> to unmute the speakers and mute the headphones and vice versa, or is
> there more to it.)
>
>
>
it is really hardware dependent

Which on-board sound driver are you using ?

auto mute is a specific feature for notebook in old day

For the desktop,  the front panel audio connector of the AC97' chassis and
HDA chassis

http://www.intel.com/support/motherboards/desktop/sb/cs-015851.htm

For some HDA codec, the headphone (front panel green jack) can be used
indpendent of the rear panel jacks on desktop