[pulseaudio-discuss] Headset-detection

[David Henningsson]

On 2011-08-03 15:05, Himanshu Chug wrote:
> Hi Colin, David
>
> I can see David posts on the group recently and assuming David is back
> from vacations :)

Your assumption is correct :-) Btw I don't mind being cc:ed if you need 
to reach me in person as I don't read all of pulseaudio-discuss normally.

> unfortunately we don't access to IRC chat due to some security
> restriction (thou we are working to get this sorted, if possible) so
> currently I can discuss only over group emails.
>
> On Fri, Jul 22, 2011 at 1:42 AM, Colin Guthrie <gmane at colin.guthr.ie
> <mailto:gmane at colin.guthr.ie>> wrote:
>
>     'Twas brillig, and Himanshu Chug at 21/07/11 08:24 did gyre and gimble:
>      > Thanks Colin and Spidey for making this clarification.
>      >
>      > So regarding JACK detection and routing:
>      >
>      > 1. module-udev-detect currently can detect JACK physical hot-plugging
>      > but it can't decode the information about what type of JACK device (
>      > input or output ) is connected to the sound-card, and for that
>     one need
>      > to write an JACK detection module to handle that.
>      > is my understanding correct ?
>
>     Not quite. Udev detect does absolutely nothing with JACKs. It detects
>     totally new devices in a hotplug way. These devices are e.g. USB
>     speakers or headsets.

Although as of now, and the preliminary implementation the UCM folks 
did, the jack input devices are being detected by udev.

> one colleague of mine from ALSA /kernel team have wrote the Jack
> detection app using udev API from libudev,
> so the Jack plug in/plug Out state can be read at
> sys/devices/virtual/switch/h2w/state
> State   Meaning
>                     0    No Headset Connected
>                     1    Headset with MIC connected
>                     2    Headset without MIC connected

This is a non-standard way of doing it, so once we have the 
infrastructure in place you'd still have to write your own module for that.

> here we are monitoring in a loop using udev monitor fd and based on the
> "state" we are calling kcontrols for loudspeaker and headset
> something like here...
>
> fd = udev_monitor_get_fd(mon);
>
> while (1) {
> ............
> r = select(fd, ...);
>
> dev = udev_monitor_receive_device(mon);
> if (dev) {
>      // Jack Inserted/Removed
>     Jack_Report(state); // this function will call kcontrols for
> headset/loudspeaker based on "state"
> }
> ............
> }
>
> I am trying to understand if this approach of Jack detection is fine?
> at-least I need to know if I am going in right direction?

If you do your own program as listed above and nothing inside 
PulseAudio, Jack_Report could call "pacmd set-sink-port", at least if 
you got your PulseAudio profiles and paths set up correctly (see 
WritingProfiles on the wiki).

>     The actual HP Jack detection stuff is not present at all in PA as the
>     underlying layers in ALSA are in flux. These need to settle before we
>     can write anything to deal with them.
>
>
> As Colin comments about ALSA layers are in flux, I need to understand
> this bit more some brief information about this problem with ALSA ?
> if you can point to some link or so is also fine :)

http://comments.gmane.org/gmane.linux.alsa.devel/86315

>     There are active discussions on this topic just now on the alsa-devel
>     mailing list.

None that I have missed I hope? :-)

>      > 2 Currently our Kernel/ALSA team support for providing seperate
>     kcontrol
>      > (amixer scripts) for enabling/disabling loudspeaker and headset
>     to PA,
>      > so it might be an good idea to handle Jack detection and routing
>     in one
>      > of the existing module or write up an new jack detection module for
>      > this, as Colin suggested, provided that we are able to recognize Jack
>      > device type  (input/mic or output/headset or both)  from point 1, ( i
>      > will take further help from kernel team here about detecting jack
>     device
>      > type, but any suggestions are welcome :-) )
>
>     Kinda. PA should be able to display to you the different "ports" for
>     each sink. These ports represent the Speakers or the Headphones
>     kcontrols that are on your device and you can change ports at runtime
>     (just run pavucontrol and if your sinks actually have ports, there will
>     be a drop downo n the "Output Devices" pane).
>
>
> I am not able to get pavucontrol installed and working on my rootstrap,
> due to some other issues, but I need to test this out also soon.

"pacmd list" should - among many other things - give you a list of ports 
and profiles for a card.

> but I tried on UBUNTU 10.10 desktop, pavucontrol app showing me the
> dropdown for Output Devices,
>
>     At present you have to
>     change ports manually but the plan is to hook this up to jack detection,
>     such that the port is simply flipped accordingly.
>
>
> I need to know where (or how) in code we can do "flipping of ports from
> headphones to loudspeaker"
> if I use our udev API for jack detection from above ?
>
>
>     Multifunction jacks (i.e. those that can be input or output, analog or
>     digital) are even more interesting :)
>
>
>     I very strongly suggest you discuss this with David Henningsson. He's on
>     this list but is away on vacation for (I think) another week. He's is
>     actively working on JACK support for ALSA and PA layers so it will
>     likely be the most productive for you if you wait and speak with him.
>     He's employed by Canonical and is diwic on IRC.

Nitpick: JACK with all caps usually refers to "Jack Audio Connection 
Kit", which is a low-latency (rather than low-power) sound server, i e 
something completely different.

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