'Twas brillig, and Jorge Eduardo Candelaria at 11/05/11 19:56 did gyre
and gimble:
>
> On May 11, 2011, at 6:43 AM, Colin Guthrie wrote:
>
>> 'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did
>> gyre and gimble:
>>> This is the third version of the Pulseaudio and UCM integration.
>>>
>>>
>>> This set of patches cover adding ucm data to proplist, adding a
>>> ucm API to get and set data to proplist, and lets
>>> module-alsa-card scan ucm data when the card is probed.
>>>
>>> Another set of patches dealing with jack module detection will
>>> be sent separately.
>>
>> Thanks for this. I believe David will be helping review this
>> stuff, but is currently at UDS.
>>
>> WRT the jack detection, I think we all agreed that it needs to be
>> handled more internally in the alsa code rather than separated as
>> a module.
>>
>> I'm not 100% sure of the finer details but I know David had ideas
>> here too.
>>
>> We basically need to match up the jack stuff with the appropriate
>> sink/source device on the system and then develop a way to
>> automatically change sink/source ports accordingly (it may also
>> require that we change the card profile too - e.g. change from a
>> 5.1 profile to a stereo profile when plugging in stereo
>> headphones).
>
> Unfortunately, the jack matching to source is not that clever yet in
> the drivers. :( There is no way to really be sure that Jack X
> matches stream Y. This information should be available in the future
> though (for ASoC drivers at least) when the DAPM graphs are exported.
> In the mean time all we can do is know whether a jack is inserted or
> removed for a particular sound card.
I thought it reported some fairly useful names.... I'm sure David had
some way to see some degree of info.
For example on my machine:
[root at jimmy ~]# cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xefebc000 irq 43
[root at jimmy ~]# evtest /dev/input/event7
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "HDA Intel Mic at Ext Right Jack"
Supported events:
Event type 0 (Sync)
Event type 5 (?)
Event code 4 (?)
Testing ... (interrupt to exit)
So the string "HDA Intel" is present in both which we should be able to
match up.
>> I'm not sure how to detect multiple jacks - e.g. if you plug in 3
>> jacks to do 5.1 output, should 5.1 be handled automatically?
>
> Again, this is something that requires better driver and core alsa
> support.
Well not sure. I'd expect the different jacks to have different
/dev/input/event* inputs with different jack names on them, so we should
(in theory) be able to match that up no?
>> Anyway, all the jack detection stuff should be totally separate
>> from UCM stuff and could in theory be committed first. UCM should
>> just hook into port/profile changes for pushing new configs up to
>> ucm and set the appropriate verb+modifiers on the device.
>
> Ok, I'll copy the jack code we have into module-alsa-card. This will
> allow for simple jack removal/insertion events to be propagated to
> pulseaudio. We won't be able to do the complicated stuff mentioned
> above, but should at least be able to do simple speaker/headphone
> switching.
Cool. Like I say it's probably worth chatting with David about it before
coding too much, but I'm not sure how contactable he is due to UDS focus
right now.
It's not possible to do anything with jack detect unless we can match up
the events with the device. If we can't do that, then we're stuck (e.g.
imagine if the user has two sound cards) so I hope what I wrote above is
indeed true!
Cheers
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/]
