mk-fg / python-pulse-control

Python high-level interface and ctypes-based bindings for PulseAudio (libpulse)
https://pypi.org/project/pulsectl/
MIT License
170 stars 36 forks source link

How to inspect an event further #67

Closed rubin55 closed 2 years ago

rubin55 commented 2 years ago

I've been playing around with pulsectl today. I re-created one of your examples, to see the events that Pulse emits:

import pulsectl

with pulsectl.Pulse('event-printer') as pulse:

    def print_events(ev):
        print('Pulse event:', ev)

    pulse.event_mask_set('all')
    pulse.event_callback_set(print_events)
    pulse.event_listen(timeout=10)

Running the above code and pressing the mic-mute toggle on my keyboard:

$ python experiment4.py 
Pulse event: facility=<EnumValue event-facility=source>, index=51, t=<EnumValue event-type=change>
Pulse event: facility=<EnumValue event-facility=card>, index=45, t=<EnumValue event-type=change>

The events seem very sparse; how can I get more information from the event object? Specifically, I'm looking to identify this event more specifically (as in: what it is, that it's a mute-toggle event, that kind of thing).

Any insights much appreciated + thanks for a great pip package!

mk-fg commented 2 years ago

Hi. Thanks.

The events seem very sparse; how can I get more information from the event object?

Don't think there's more data in the pulse events - it's actually just one number, which includes e.g. PA_SUBSCRIPTION_EVENT_CARD bit for facility and PA_SUBSCRIPTION_EVENT_CHANGE bit for event type. And there's also an index of the card/sink/source/etc in question. You can then query the object by index and get whatever properties that way.

Specifically, I'm looking to identify this event more specifically (as in: what it is, that it's a mute-toggle event, that kind of thing).

Same idea as above - don't think such info appears in pulse events, and it probably doesn't go beyond module-mmkbd-evdev or such, that listens for evdev events and changes source/card parameters. So from the main daemon's perspective it's also just a change in source/card properties.

If the goal is to check if mute has been toggled in pulseaudio (via whatever mechanisms configured there), then querying source properties on such change events seem to be indeed the way to go. But if it is to check for multimedia button presses and do something custom in response to those, then I think you'd probably want to listen to events on same evdev devces yourself and react to those (check out /proc/bus/input/devices, evtest tool and pyevdev module for that).