Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
On Tue, 2011-04-12 at 21:58 +0100, Mark Brown wrote: On Tue, Apr 12, 2011 at 02:14:04PM -0500, pl bossart wrote: Jack detect does not use the ALSA kernel subsystem but does instead use the input subsystem for jack status. It makes sense to create a new module so we can then use jack detect for non ALSA sound devices. I'm a bit lost here. What are 'non ALSA sound devices'? And to the best of my knowledge these events are only generated by ALSA drivers... Am I missing something here? These events can be generated by anything - prior to my implementing the ALSA support for this all the implementations in mainline were doing this via the gpio-keys driver since they were detecting a microswitch in the jack. I'd expect that non-audio jacks may also end up reporting via the same interface (video for example), but I'm not sure if Pulse would be interested in anything non-ALSA. Yeah, this was one of the considerations here along with any OSS audio cards (as there are still a few OSS drivers upstream). This can be moved and integrated into module-alsa-card if desired ? Liam ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
Jack detect does not use the ALSA kernel subsystem but does instead use the input subsystem for jack status. It makes sense to create a new module so we can then use jack detect for non ALSA sound devices. I'm a bit lost here. What are 'non ALSA sound devices'? And to the best of my knowledge these events are only generated by ALSA drivers... Am I missing something here? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
On Tue, Apr 12, 2011 at 02:14:04PM -0500, pl bossart wrote: Jack detect does not use the ALSA kernel subsystem but does instead use the input subsystem for jack status. It makes sense to create a new module so we can then use jack detect for non ALSA sound devices. I'm a bit lost here. What are 'non ALSA sound devices'? And to the best of my knowledge these events are only generated by ALSA drivers... Am I missing something here? These events can be generated by anything - prior to my implementing the ALSA support for this all the implementations in mainline were doing this via the gpio-keys driver since they were detecting a microswitch in the jack. I'd expect that non-audio jacks may also end up reporting via the same interface (video for example), but I'm not sure if Pulse would be interested in anything non-ALSA. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
I've not looked specifically at the code, but I'd have expected that jack detection would somehow be built into module-alsa-card or module-alsa-source/sink rather than shipped as a separate module (tho' I'm maybe not appreciating some intricacy here)... I'll try and review the code soon (although others may have beaten me to it anyway :D) Well the UCM code corresponding on what to do when jack is plug or unplug its part of module-alsa-card but we had to add first the logic in PA to detect the jack insertation/removel that it is basically a listener of /dev/input/eventX, that is used by the kernel to report the event. All the logic for jack detection has been added in a new module. I'll wait your feedback/questions related to UCM integration :) I have pretty much the same feedback as Colin. First I cherry-picked the two jack-sensing patch and installed them on my laptop (68293cd29b1dcb6b555edeaa5d63110164e5c794 and 6c4a7de60040d5dc3d3b44461a7f490e3feba26f). Works fine, the events are detected. This is something that we've needed for some time. Thanks! But then I looked a the flows and was confused by the design. - It's not clear why you would create a new thread using pthreads rather than pa_create_thread()? Is there any technical reason why the abstraction isn't enough - this thread blocks on a read, and whenever a jack insertion/removal is detected it fires a Hook which is then used by module-alsa-card to actually switch profiles in two callbacks. Why not implement this thread as part of module-alsa-card then? What if the benefits of using the hook as a communication means between two modules? I can see though the benefit of using a hook for, say, an effect that is enabled only for a headphone. That is more the intended use of a hook I believe. While I am at it, I am not even sure you need a thread for this with all the event loops, iochannels and stuff that PulseAudio/glib provide. We may also want to switch the card profiles even if the card isn't supported by UCM. Last, I looked at the two callbacks you implemented, looks to me that the insert and remove parts do the same thing? Shouldn't you memorize the current device, switch to the headphone upon jack insertion and restore the previous device on removal? Maybe this needs to be linked with how PulseAudio memorizes the devices or Colin's device-manager? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
Hiya Maggie, 'Twas brillig, and Margarita Olaya at 11/03/11 16:50 did gyre and gimble: The second thing is to figure out what we should really do once we have detected jack insertion or removal. Adding a hook event and let other modules act on that, seems reasonable to me. But we should also add a property to the property list (or something similar?) telling the current state of the jack - and btw, can this be figured out by reading from /dev/input/eventX at startup? atm the target is to used it along with the UCM module, so once we have detected jack insertion or removal the UCM will configure the sound card for it, so we need a (new?) hook to notify the other modules. Sorry for lack of replies from me of late... been a bit swamped at $DAYJOB :p Am I right in saying that you basically have to set appropriate verbs via UCM when the jack is inserted? In my mind, jack detection should basically change the sink/source ports only. Then the UCM module would hook into the fact that the port had changed to do it's magic (there are existing hooks for this already in place). That way jack detection is technically separated from UCM via the abstraction of sink/source ports in PA. We discussed a similar logic for setting verbs on IRC. http://colin.guthr.ie/meetings/pulseaudio-meeting/2011/pulseaudio-meeting.2011-02-24-21.02.log.html#l-146 This may not be entirely possible depending on what you actually need to do with UCM... but perhaps it will fit in nicely. I've not looked specifically at the code, but I'd have expected that jack detection would somehow be built into module-alsa-card or module-alsa-source/sink rather than shipped as a separate module (tho' I'm maybe not appreciating some intricacy here)... I'll try and review the code soon (although others may have beaten me to it anyway :D) 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
Hi Pierre, On Mon, Apr 4, 2011 at 1:05 PM, pl bossart bossart.nos...@gmail.com wrote: Margarita: I wasn't really able to try out your patches and figure out what they entail since your version of pulseaudio is _very_ old. I tried to merge them one by one, you'll find the result attached. I compiles with git master and if UCM is disabled in module-alsa-card things seem to work fine, so no side effects. Can you let me know if I missed something, and better yet, can you move to something more recent? Yes, it was an old branch but I have moved the code to master branch. I'm just finishing to work on some comments that I got so I'll post the latest code tomorrow. Regards, Margarita Thanks, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
Hi David, On Fri, Mar 11, 2011 at 1:12 AM, David Henningsson david.hennings...@canonical.com wrote: On 2011-03-10 22:47, Margarita Olaya wrote: Hi, I have some initial code for jack sense implementation, the approach is to listen /dev/input/eventX and pass that data as argument to a new module called module-jack-detect where a thread wakes when the jack has been inserted. Using the current code I'm able to catch jack insertion and removal, next step is to signal PA core when the jack has been inserted so this calls a hook in the PA UCM module to load the ucm configuration for jack. Jack sense is something that we all want, so it's great that someone is working on it. The first tricky thing is to match /dev/input/eventX against the proper card - that is, if you have three cards, all with headphone outputs, you must know which card your event belongs to. Is this solved in your git tree? I had a quick look but couldn't find code for doing that. (You also seem to add threads for all eventX, even those not audio related at all, could this be improved?) The card name is passed as argument to the jack module, it checks each event device to see if it belongs to a sound card otherwise the event is ignored. The jack module is loaded one time per card so we collect the data for each card. So, I need to send a message to any other interested module but I'm sure how implement it, Can a hook be used to signal PA core? The second thing is to figure out what we should really do once we have detected jack insertion or removal. Adding a hook event and let other modules act on that, seems reasonable to me. But we should also add a property to the property list (or something similar?) telling the current state of the jack - and btw, can this be figured out by reading from /dev/input/eventX at startup? atm the target is to used it along with the UCM module, so once we have detected jack insertion or removal the UCM will configure the sound card for it, so we need a (new?) hook to notify the other modules. Regards, Margarita -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
On 2011-03-10 22:47, Margarita Olaya wrote: Hi, I have some initial code for jack sense implementation, the approach is to listen /dev/input/eventX and pass that data as argument to a new module called module-jack-detect where a thread wakes when the jack has been inserted. Using the current code I'm able to catch jack insertion and removal, next step is to signal PA core when the jack has been inserted so this calls a hook in the PA UCM module to load the ucm configuration for jack. Jack sense is something that we all want, so it's great that someone is working on it. The first tricky thing is to match /dev/input/eventX against the proper card - that is, if you have three cards, all with headphone outputs, you must know which card your event belongs to. Is this solved in your git tree? I had a quick look but couldn't find code for doing that. (You also seem to add threads for all eventX, even those not audio related at all, could this be improved?) So, I need to send a message to any other interested module but I'm sure how implement it, Can a hook be used to signal PA core? The second thing is to figure out what we should really do once we have detected jack insertion or removal. Adding a hook event and let other modules act on that, seems reasonable to me. But we should also add a property to the property list (or something similar?) telling the current state of the jack - and btw, can this be figured out by reading from /dev/input/eventX at startup? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
