Support for acpid protocol

[kferrone]

Is your feature request related to a problem? Please describe.
None of the existing protocols nor the ones planned are able to detect speakers getting plugged into an audio jack.

Is your feature request related to a way you would like Akri extended? Please describe.
No support for using devices plugged into an audio jack. Basically a new protocol for acpid should be added.

Describe the solution you'd like
Ability to use speakers/headphones/microphones plugged into an audio jack using the acpid protocol.

Describe alternatives you've considered
As of now one could only use usb speakers with udev.

Additional context
Still confused why I can't simply just mount /dev/snd

Here is the output of a test I ran which involved unplugging and plugging some headphones in using acpi_listen

kelly@rocky:~$ acpi_listen
jack/headphone HEADPHONE unplug
jack/microphone MICROPHONE unplug
jack/headphone HEADPHONE plug
jack/microphone MICROPHONE plug

[kate-goldenring]

Hi @kferrone, even if plugged in via the headphone jack, I would expect the speakers to still be a part of the Linux device file system and therefore discoverable via udev. Like you said, your speakers may be under /dev/snd in which case you could use the udev rule SUBSYSTEM=="sound". But I am assuming there are other sound devices there besides your speakers, so you may need a more specific rule. Determining the udev rule has certainly been tricky

[kferrone]

We have discovered the /dev/snd directory is special and the entire folder is needed unlike other devices in /dev.
Well at least all devices related to at least one sound card and the seq and timer as well.
Also the only true 'device' for sound is the sound card and anything you plug into the Audio jack is a device connected to a device, a meta device I guess.

Basically UDEV would only ever see you un/plugging the sound card, not speakers through the audio jack. Therefore acpid would be needed to discover anything connecting to the audio jack.

Another issue with sound and UDEV is using HDMI or USB for audio. Basically UDEV would trigger from USB and HDMI but how would you know it is an audio device? You would still need to mount dev/snd to play any sound out of it, probably would need to mount the device for USB or HDMI as well.

[kate-goldenring]

Thanks for confirming that udev doesn't fit the scenario of audio jack or determining specific sound devices! ACPID sounds like a good protocol, especially since it captures other events too besides connecting to the audio jack such as the ones you listed in Slack ( sleep/power button, power cables getting plugged in or out). My question with this protocol is determining what would need to be mounted into brokers. For example, a jack/headphone HEADPHONE plug ACPID event would need /dev/snd mounted by some other event may need a different device directory mounted.

[kate-goldenring]

Further discussion on ACPID as a protocol can be referenced from this thread in Slack.

[github-actions]

Issue has been automatically marked as stale due to inactivity for 45 days. Update the issue to remove label, otherwise it will be automatically closed.

[bfjelds]

@kferrone , is this a scenario that should be prioritized?

[kferrone]

Maybe. I just discovered it is what is needed to discover headphones/aux inputs. Would be a nice addition to Akri. I have no idea how to implement such a thing though. I only needed it for a home project so I could easily plug speakers into any node and have snapcast client run as the broker.

[kate-goldenring]

I could see us using this rust ALSA library to search for devices and then if the desired one is found, then the entire /dev/snd directory is mounted into the broker. It dont think it would be too complex of a discovery handler and could work off our template. If you are interested in implementing it, I'm certainly happy to help. It also doesnt have to be in Rust, rather it could be in any language so long as it implements our gRPC interface.

[github-actions]

Issue has been automatically marked as stale due to inactivity for 90 days. Update the issue to remove label, otherwise it will be automatically closed.