Hi Colin, David
I can see David posts on the group recently and assuming David is back from
vacations :)
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> 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.
>
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
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?
> 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 :)
> There are active discussions on this topic just now on the alsa-devel
> mailing list.
>
>
> > 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.
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.
>
>
> Col
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
> Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
> Mageia Contributor [http://www.mageia.org/]
> PulseAudio Hacker [http://www.pulseaudio.org/]
> Trac Hacker [http://trac.edgewall.org/]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110803/86b40519/attachment.htm>
