You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seeing the recent Desktop companion PR from @RobinDadswell fixing Audio not playing on Desktop companion seems to be related to Sendspin issues with audio output sources (or the apparent lack thereof), I am curious as to how you would tackle forcing a re-connect of a Bluetooth speaker to a desktop PC (here windows) ?
Context and dream :
It is partially related to that issue, as every MA user's dream is native Bluetooth audio management. But I'm curious if MA can be a bridge for force-reconnect commands of bluetooth devices (here, speakers obviously) on some of its players ? Is such a protocol or bridge even possible?
Notifications :
Alternatively, my current solution for TTS is using HASS.agent to send an obscure shell command that uses Bluetoothcl to force connect my speaker to the MediaPC, prior to sending any TTS commands. It works quite well actually, and the soundbar turns on and reconnects within a few seconds to the Media PC, bringing it as the source. Better yet, HASS agent has sensors for BT connected devices and Audio source, so I can get feedback thru a sensor as to which "source" is currently used by the Media PC to confirm it is "safe" to execute the TTS action.
So much so that I created a custom script to automate the whole thing: "reconnect first, then once audio output source is the BT speaker, send the notification on a Notificator group the Media PC is part of". (pending approval of the PR I mentioned obviously, which I hope will fix my issue).
Music playback :
That is obviously a bit more tricky with direct play on Music Assistant however. Even if the media player of the Music Assistant is still on, after a long idle my BT speaker will turn off (i'd rather avoid the white noise tricks and waster power). Thus, I doubt i can "hijack" the play command or the queue from MA to delay until my bluetooth speaker is properly reconnected to the Media PC, can I? If so, any idea what's the best course of action for this?
My initial thoughts is a general dumb "Let's start listening to music" button helper in HA that would trigger the same sort of script I built for the notifications: once pressed, reconnect the soundbar, then put anything to the queue of the player group that mediapc is part of. But that's a bit hacky and obviously very low wife approval factor...
Curious about your ideas and how you would approach this. Curious even more if the Desktop companion app could potentially support an "Audio source" option that's available from Music Assistant server itself, with better yet a way to select /search for bluetooth devices there.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Seeing the recent Desktop companion PR from @RobinDadswell fixing Audio not playing on Desktop companion seems to be related to Sendspin issues with audio output sources (or the apparent lack thereof), I am curious as to how you would tackle forcing a re-connect of a Bluetooth speaker to a desktop PC (here windows) ?
Context and dream :
It is partially related to that issue, as every MA user's dream is native Bluetooth audio management. But I'm curious if MA can be a bridge for force-reconnect commands of bluetooth devices (here, speakers obviously) on some of its players ? Is such a protocol or bridge even possible?
Notifications :
Alternatively, my current solution for TTS is using HASS.agent to send an obscure shell command that uses Bluetoothcl to force connect my speaker to the MediaPC, prior to sending any TTS commands. It works quite well actually, and the soundbar turns on and reconnects within a few seconds to the Media PC, bringing it as the source. Better yet, HASS agent has sensors for BT connected devices and Audio source, so I can get feedback thru a sensor as to which "source" is currently used by the Media PC to confirm it is "safe" to execute the TTS action.
So much so that I created a custom script to automate the whole thing: "reconnect first, then once audio output source is the BT speaker, send the notification on a Notificator group the Media PC is part of". (pending approval of the PR I mentioned obviously, which I hope will fix my issue).
Music playback :
That is obviously a bit more tricky with direct play on Music Assistant however. Even if the media player of the Music Assistant is still on, after a long idle my BT speaker will turn off (i'd rather avoid the white noise tricks and waster power). Thus, I doubt i can "hijack" the play command or the queue from MA to delay until my bluetooth speaker is properly reconnected to the Media PC, can I? If so, any idea what's the best course of action for this?
My initial thoughts is a general dumb "Let's start listening to music" button helper in HA that would trigger the same sort of script I built for the notifications: once pressed, reconnect the soundbar, then put anything to the queue of the player group that mediapc is part of. But that's a bit hacky and obviously very low wife approval factor...
Curious about your ideas and how you would approach this. Curious even more if the Desktop companion app could potentially support an "Audio source" option that's available from Music Assistant server itself, with better yet a way to select /search for bluetooth devices there.
Beta Was this translation helpful? Give feedback.
All reactions