Open GioF71 opened 7 months ago
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.
@tehkillerbee , Off-Topic: do you believe that an external USB DAC is better than taking the audio from the HDMI?
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.
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?
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
Do you think we can open an issue on mopidy?
What receiver/converter do you use?
A Triad Control-4 amplifier
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?
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
I will test ASAP, however work has been keeping me busy these weeks. Sorry!
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!
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).
Thank you!
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