Related to Github issue #21.
When using the Openhome ohPlayer I noticed that a halt flag is set when playback is paused or stopped and unset if not. In case of a stop, two or three empty messages are received after the audio message containing the halt flag.
I would like to use this to information in the ALSA audio backend to open/close the ALSA device depending on the state. This way, the ALSA device is only used if playback does actually happens.
Any thoughts?
Discussion
-
medoc
2017-07-10- milestone: 1.0 -->
-
medoc
2017-07-10I've had a look at what happens with Windows Songcast as the Sender. I get a halt message then mediaplayer Stops or Pauses, and when the Sender is told to disconnect and go back to local playing (so this would work, except that it would be a bit awkward to turn things off on pause, maybe).
I get no halt message whatsoever when the sender is mpd2sc, and I see nothing in the ohSongcast code which would set the Halt flag. I don't think that this could be done in mpd2sc.cpp, this just generates the audio data for the openhome code which calls it.
So probably the only way to make this work would be to switch to the new ohPipeline code. I had a quick look, but this is vastly more complicated, and I'm not too sure at this point how the current sender can be grafted in there.
I wonder if it would be possible to execute something to turn the amp off when we've not seen sound for some time ? This might be just simpler than switching to the new code, which we admittedly may have to do at some point anyway...
Also, I'm going away tomorrow for 1 week, so don't be surprised if I'm silent for a while :)
Last edit: medoc 2017-07-10-
jk
2017-07-24It took my a while to understand how the audio data are exactly flowing from the pipe through the queues to the ALSA device.
The halt branch is the result of my approach to pass the halt flag to the Songcast receivers.
As the Songcast Sender is not responsible for the audio stream, but only for broadcasting, the responsibility for controlling the audio stream is put to the stream producer.
Therefore, I added a socket interface to control the Songcast Sender. I've tested this with a Spotify application, which runs a user command when playback begins and ends.
To get the series of patches to work, the ohSongcast library needs to be patched: https://github.com/joerg-krause/ohSongcast/commits/halt.
I am quite satisfied with the result, but I would be glad for your review.
-
medoc
2017-07-26Ok I merged this with a small difference:
I am protecting the 3-argument SendAudio calls with#ifdef HAVE_SENDAUDIO_PAUSE_FLAGso that things continue to work with the standard lib. You will have to add the flag to the modified lib include file or to the build.
Last edit: medoc 2017-07-26-
jk
2017-07-26Wow! Thanks for merging. Didn't expected it. I will propose a patch to check for HAVE_SENDAUDIO_PAUSE_FLAG in configure. Okay?
-
medoc
2017-07-26I did not see a problem with the patch, so why not merge it :) it's an alternate way to do things compared to the timeout-based approach in my changes.
I guess that you mean a configure test to check for the number of arguments and set the HAVE_xx flag if needed ? Yes, this would be nice :)
-
jk
2017-07-26I think both ways are helpful, as you're approach helps if the Sender is not reliable or shutdown before he can say goodbye.
Yes, I mean a configure test.
I opened a pull request on the ohSongcast repo. Let's see, if anybody cares.
-
jk
2017-07-27I rebuild sc2mpd using your master branch. When the Sender sents the halt flag, the receiver has a deadlock in alsadirect, because of the alsa_mutex. I fixed it by adding a new scope around the lock in alsawriter():
{ std::unique_lock<std::mutex> lock(alsa_mutex); if (pcm == nullptr) { if (!alsa_init(alsadevice, tsk)) { alsaqueue.workerExit(); return (void*)1; } } }
Not sure if this is a proper fix.