Every time I play a stream via gmrender (UPnP renderer) it won’t release the hardware audio interface after it’s done playing. So in order to make another client work (e.g., raspotify) I have to login to DietPi and manually restart gmrender service first. Is there any way to prevent such behavior? Raspotify does not have this problem, I can switch from it to gmrender seamlessly. But not the other way round – the moment I use gmrender it grabs the interface and nothing else can use it until gmrender is restarted.
My system is Allo USBridge / Sparky SBC / DietPi v6.21.1
I just checked my combination of Gmrender and Shairport Sync, and found that Gmrender does not release the ALSA device, if I just pause the UPnP Stream. If I stop the stream, the audio device is released and can be accessed by Shairport Sync. I use 8player to send Audio from my Plex DLNA server to the Gmrender device. So I suppose Gmrender works as expected.
In contrast, the transisition from Shairport to Gmrender most of the times only works when I disconnect Airplay completely.
If there is no other way to get your system to run as desired, you might check out the ALSA dmix plugin, as explained here for example: https://stackoverflow.com/questions/14398573/alsa-api-how-to-play-two-wave-files-simultaneously
This might be by design but then it is a bad design, and that’s my point actually.
None of the mobile player apps I am using have a “true” stop button anymore. All they have are pause buttons. I mostly use HiFi Cast and BubbleUPnP for streaming to DLNA renders from my Android phones and Nexus 7 tablet. If you select DietPi gmediarender as a playback device from either of these apps this device will stay selected even after you exit the app. And if you try raspotify playback after that it will fail. You need to explicitly switch back to local device in UPnP player in order to ensure gmrender releases audio device on the server.
On the contrary, when I play from Spotify app via raspotify render on DietPi server, it also does not have stop button, however, when I push pause button and exit the app it will release interface on the server automatically. No need to manually switching to local device playback. Moreover, it would still remember last device used and restart playback on this device next time I run it. But it wiil not attempt to grab audio interface until I actuilly click on the play button. As a result, I can have Spotify app happily sitting paused in the background and still start BubbleUPnP and stream from it to gnrender, all without any extra effort. That’s what I call proper design.
Unfortunately, this does not work the other way round since gmrender never releases audio interface once it has grabbed it. Even if I restart my phone to make sure no copies of BubbleUPnP is running in the background anymore, the audio interface on the server is still locked. Only gmrender service restart will make it release server interface. I call this a bug, or poor design if you prefer. I do not see how one can argue this might be a reasonable behavior.
I agree a proper design should release the audio interface once playback stops. But perhaps it was simply not intended so far to use different sound sources why this was never implemented. We could try to ask for this feature by opening a GitHub issue: https://github.com/hzeller/gmrender-resurrect
However the dev is not very active and PRs + issues stay unanswered for a long time.
Switching sound source between spotifyd and shairport-sync btw seems to work fine: https://github.com/MichaIng/DietPi/issues/2610
(On Sparky SBC it throws kernel errors, but aside that works well.)
Apparently, BubbleUPnP author reads DietPi forums. My phone has received a BubbleUPnP update yesterday and one of the features added was an option to enable genuine “stop” button right on the “now playing” screen. I have tried it and it worked like a charm. So I can now switch playback between BubbleUPnP/gmrender and Spotify/raspotify seamlessly without audio interface lockups. Nice!
Ahhh that is very great news. Thanks for reporting this!
Hmm so it is up to the clients to close connections or at least they can force GMRender to release the audio device . Good to know.
I do have a similar issue but with a different setup, i dont know if you can help me with it but… here is my set up and issue.
- DS 218+ NAS with BubbleUpnp server (creating an openhome network)
- RP4 with Dietpi & Gmrender as openhome renderer
- A Topping D50s usb dac connected to the RP4
- Android Smartphone with Bubbleupnp app.
One of the DAC feature is turning ON when he receive some audio file and turning OFF when music stop.
When i play some Qobuz music with bubblepnp from my smartphone, it does turn ON the dac and play the music.
When i stop playing music, it nerver release the dac and the dac never turn off.
I’ve tried both “stop” and “shutdown app” buttons on bubbleupnp.
Do you think that could come from dietpi, gmrender or bubblepnp ?
Not sure, as above, the stop button should release the audio device.
Does GMediaRender produce any errors?
journalctl -u gmediarender
No, it doesn’t :
root@DietPi:~# journalctl -u gmediarender
-- Logs begin at Thu 2021-04-29 19:27:02 CEST, end at Sun 2021-05-02 19:11:22 CEST. --
-- No entries --
Ah sorry, wrong service name:
journalctl -u gmrender
well, there is actualy a lot of logs . What should i look for ?
Should i “| grep” something or can i “tail -f” the command and check in real time ?
journalctl -u gmrender -f would be tail the log constantly until you cancel it
Here is the end of the logs, i’ve played 8 sec of a track
mai 03 10:12:24 DietPi gmediarender: INFO [2021-05-03 10:12:24.172597 | transport] RelativeTimePosition: 0:00:06
mai 03 10:12:25 DietPi gmediarender: INFO [2021-05-03 10:12:25.173724 | transport] RelativeTimePosition: 0:00:07
mai 03 10:12:26 DietPi gmediarender: INFO [2021-05-03 10:12:26.174805 | transport] RelativeTimePosition: 0:00:08
mai 03 10:12:27 DietPi gmediarender: INFO [2021-05-03 10:12:27.174412 | transport] TransportState: STOPPED
mai 03 10:12:27 DietPi gmediarender: INFO [2021-05-03 10:12:27.174495 | transport] CurrentTransportActions: PLAY,SEEK
mai 03 10:12:27 DietPi gmediarender: INFO [2021-05-03 10:12:27.174674 | transport] LastChange: <?xml version="1.0"?>
mai 03 10:12:27 DietPi gmediarender: <Event xmlns="urn:schemas-upnp-org:metadata-1-0/AVT/">
mai 03 10:12:27 DietPi gmediarender: <InstanceID val="0">
mai 03 10:12:27 DietPi gmediarender: <TransportState val="STOPPED"></TransportState>
mai 03 10:12:27 DietPi gmediarender: <CurrentTransportActions val="PLAY,SEEK"></CurrentTransportActions>
mai 03 10:12:27 DietPi gmediarender: </InstanceID>
mai 03 10:12:27 DietPi gmediarender: </Event>
It seems to be “STOPPED”.
So i guess the app is sending the correct information ?
yap looks like an Event was sent with a value STOPPED.
After reading this post :
It could be an usb power issue.
I’m going to try and test differents configurations and see.
But it’s maybe not a Dietpi issue or question, so i won’t bother you more with this
Thanks you both for your help !
I wouldn’t wonder indeed. USB power is a typical issue on SBCs, although I’d have expected the Sparky SBC to be prepared well for USB DACs in this regards .
While it may not be a DietPi issue, it would be great to know if you found a solution, so probably we can add it to our docs, e.g. our GMediaRender docs, of as part of a general troubleshooting part when it comes to blocked audio devices .
Sure, i will let you know if i find a solution.