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

Pausing Playback does not release audio device #159

Open
GioF71 opened this issue Mar 4, 2024 · 13 comments
Open

Pausing Playback does not release audio device #159

GioF71 opened this issue Mar 4, 2024 · 13 comments

Comments

@GioF71
Copy link

GioF71 commented Mar 4, 2024

Hello, I don't know if this is related to your plugin (I would say no, but I am asking you).
The issue I am experiencing is that when I hit pause, the audio device is not released.
Even if a play queue complete its run, the audio card is not released.
The only way I can get the audio device released is to have something on the play queue and then press "Clear".
The previous scenario (when the queue is played) is the worst, because in that case, hitting clear does not release the audio device. I need to put something up for playback, then hit clear, and then I can finally use some other app that wants to access the device.

Does this happen to you too?
If so, is that related to your plugin, to Iris, or to Mopidy itself?

Thank you

@GioF71 GioF71 changed the title Playback pause does not release audio device Pausing Playback does not release audio device Mar 4, 2024
@tehkillerbee
Copy link
Owner

tehkillerbee commented Mar 6, 2024

I believe clicking pause results in GStreamer pausing GST_STATE_PAUSED, i.e. the audio device is still in use.

However, I would've expected that finishing the queue would release the audio device, similarly to clearing the playlist (during playback) so this sounds like a bug, perhaps in mopidy itself.

I can confirm that audio device is not released when queue is finished or if clearing queue when no playback is taking place. It only seems to be released when clearing during actual playback.

I have always used mopidy-tidal in a headless configuration or with autoaudiosink, where this issue is not noticed. I have only recently started using a "shared" USB DAC when I switched to your docker container.

@fmarzocca
Copy link

@tehkillerbee , Off-Topic: do you believe that an external USB DAC is better than taking the audio from the HDMI?

@GioF71
Copy link
Author

GioF71 commented Mar 6, 2024

I have always used mopidy-tidal in a headless configuration or with autoaudiosink, where this issue is not noticed. I have only recently started using a "shared" USB DAC when I switched to your docker container.

Hello, but this happens because it's shared (causing you to notice, because you cannot switch to another app using the same dac), or is this uniquely related to the fact you're using my docker image?
Because other than the mopidy docker image, I am running squeezelite, mpd, librespot, shairplay, each in its container, and none of them expose the same issue.

@tehkillerbee
Copy link
Owner

tehkillerbee commented Mar 6, 2024

causing you to notice, because you cannot switch to another app using the same dac

Exactly. I think this is unrelated to your docker image. For the last couple of years, I have only used mopidy-tidal in a headless configuration, where mopidy is the only user of the DAC.

do you believe that an external USB DAC is better than taking the audio from the HDMI?

HDMI is digital audio so it really depends on whatever DAC you use to convert HDMI audio to analog (eg. if you use a receiver with HDMI input). I believe HDMI supports 8 channels with 192kHz per channel (uncompressed), so as long as you are not exceeding this rate, HDMI should be fine. What receiver/converter do you use?

@GioF71
Copy link
Author

GioF71 commented Mar 15, 2024

causing you to notice, because you cannot switch to another app using the same dac

Exactly. I think this is unrelated to your docker image. For the last couple of years, I have only used mopidy-tidal in a headless configuration, where mopidy is the only user of the DAC.

do you believe that an external USB DAC is better than taking the audio from the HDMI?

HDMI is digital audio so it really depends on whatever DAC you use to convert HDMI audio to analog (eg. if you use a receiver with HDMI input). I believe HDMI supports 8 channels with 192kHz per channel (uncompressed), so as long as you are not exceeding this rate, HDMI should be fine. What receiver/converter do you use?

Hello, I just wanted to see if there are some news.
About the second part of your post and in particular the question you ask, that one is not for me I believe, I didn't post statement you commented.

Cheers

@GioF71
Copy link
Author

GioF71 commented Mar 15, 2024

Do you think we can open an issue on mopidy?

@fmarzocca
Copy link

What receiver/converter do you use?

A Triad Control-4 amplifier

@tehkillerbee
Copy link
Owner

tehkillerbee commented Mar 15, 2024

Do you think we can open an issue on mopidy?

Well we should make sure this is not caused by mopidy-tidal. Looking at the mopidy sources, all the GstState stuff takes place here: https://github.com/mopidy/mopidy/blob/main/src/mopidy/audio/actor.py

TidalPlaybackProvider is based on mopidy.PlaybackProvider class, described here:
https://github.com/mopidy/mopidy/blob/main/src/mopidy/backend.py

When we finish playing a track/playlist, this should be signaled to mopidy somehow. I assume this happens behind the scenes, judging from the documentation: https://docs.mopidy.com/stable/api/audio/#audio-api

So we do the bare minimum; just as instructed by the documentation; i.e. we provide translate_uri() and let mopidy handle the rest.

Pausing playback should NOT release the audio device. Only stopping playback would ensure that. And for some reason stop is not called when a playlist finishes. So maybe something is indeed wrong in mopidy's end?

@GioF71
Copy link
Author

GioF71 commented Mar 16, 2024

Do you think we can open an issue on mopidy?

Well we should make sure this is not caused by mopidy-tidal. Looking at the mopidy sources, all the GstState stuff takes place here: https://github.com/mopidy/mopidy/blob/main/src/mopidy/audio/actor.py

TidalPlaybackProvider is based on mopidy.PlaybackProvider class, described here: https://github.com/mopidy/mopidy/blob/main/src/mopidy/backend.py

When we finish playing a track/playlist, this should be signaled to mopidy somehow. I assume this happens behind the scenes, judging from the documentation: https://docs.mopidy.com/stable/api/audio/#audio-api

So we do the bare minimum; just as instructed by the documentation; i.e. we provide translate_uri() and let mopidy handle the rest.

Pausing playback should NOT release the audio device. Only stopping playback would ensure that. And for some reason stop is not called when a playlist finishes. So maybe something is indeed wrong in mopidy's end?

Hello @tehkillerbee, a few moments ago I tried playback using the "File" plugin, and it behaves exactly in the same way. I would say the issue is in mopidy. Would it be possible for you to verify that?

Thank you

@tehkillerbee
Copy link
Owner

I will test ASAP, however work has been keeping me busy these weeks. Sorry!

@GioF71
Copy link
Author

GioF71 commented Mar 21, 2024

Hello, sorry for the off-topic. I just wanted to ask if it would be ok for you if I open issues for feature requests on your repository.
Thank you!

@tehkillerbee
Copy link
Owner

tehkillerbee commented Mar 21, 2024

I open issues for feature requests on your repository

Of course! Feature, bug reports requests etc. are very welcome to both mopidy-tidal (and tidalapi), however due to limited time I cannot promise that they will be fixed (quickly).

@GioF71
Copy link
Author

GioF71 commented Mar 21, 2024

Thank you!

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

3 participants