Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for acpid protocol #174

Open
kferrone opened this issue Dec 14, 2020 · 9 comments
Open

Support for acpid protocol #174

kferrone opened this issue Dec 14, 2020 · 9 comments
Labels
enhancement New feature or request keep-alive

Comments

@kferrone
Copy link

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
@bfjelds bfjelds added the enhancement New feature or request label Dec 14, 2020
@kate-goldenring
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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 kate-goldenring added this to Triage needed in Akri Roadmap Jan 11, 2021
@Britel Britel moved this from Triage needed to In progress in Akri Roadmap Jan 11, 2021
@kate-goldenring
Copy link
Contributor

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

@Britel Britel moved this from In progress to Backlog in Akri Roadmap Feb 1, 2021
@github-actions
Copy link
Contributor

github-actions bot commented Sep 9, 2021

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.

@github-actions github-actions bot added the stale label Sep 9, 2021
@bfjelds
Copy link
Collaborator

bfjelds commented Nov 2, 2021

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

@github-actions github-actions bot removed the stale label Nov 3, 2021
@kferrone
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Feb 11, 2022
@romoh romoh added keep-alive and removed stale labels Apr 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request keep-alive
Projects
Status: Backlog
Development

No branches or pull requests

4 participants