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

(Reopen) "always_on" not working for ALSA devices #1623

Open
Cleric-K opened this issue Sep 21, 2022 · 6 comments
Open

(Reopen) "always_on" not working for ALSA devices #1623

Cleric-K opened this issue Sep 21, 2022 · 6 comments

Comments

@Cleric-K
Copy link

I'm not sure if #1599 gets attention since it is closed but the always_on option currently doesn't work for ALSA. I have described in the last post of the issue that simple change in the code makes it work. Is it intended that ALSA doesn't support always_on? From my experience everything works perfectly well with the above mentioned code change.

@GK-774
Copy link

GK-774 commented Sep 25, 2022

Yes, correct "always_on"does not work, reports as "closed". If this cannot cannot be controlled from within mpd it would preferable to remove the option.

@Cleric-K
Copy link
Author

Yes, in the way the code is compiled right now it does not work. But as explained in the linked issue, by modifying AlsaOutput::Pause() to return true, everything works great, as far as my tests have gone. So my question is why don't we simply change the return value of the method and make always_on work with ALSA? Is there something I'm overlooking? Maybe something that will break down in this way, something that I haven't covered in my tests?

@GK-774
Copy link

GK-774 commented Sep 27, 2022

If you simply return "true", always_on "no" (or having it not defined at all) would not work, it would be "on" in any case, no? Or have I misunderstood this?

@GK-774
Copy link

GK-774 commented Sep 27, 2022

Please disregard my last comment. Just tried it and yes, this makes it work as expected.

@GK-774
Copy link

GK-774 commented Sep 27, 2022

Well, no. It keeps the output open but consumes 100% cpu when stopped. With always_on "no" it behaves normal. It´s probably not a good idea at all at least not for an USB audio device.

@Cleric-K
Copy link
Author

Hm, you are right. Since I use the device only for audio player I haven't noticed the high cpu. I'll try to look through the code if I can spot something. Most certainly the high cpu comes from some code that keeps looping as fast as the cpu allows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants