Issue 21

The current ALSA implementation has the drawback, that the ALSA device is opened when Songcast Receiver mode starts, but is never closed. This may be an issue when using external amplifiers, which are shutdown when the ALSA device is closed.

This commit changes the moment the ALSA device is initialized, by setting a flag when the Songcast Receiver driver is PLAYING. If the Songcast Receiver driver is STOPPED, the ALSA device is closed.

I had a look at this, but the STOPPED routine never seems to be called, so I don’t really see the point. I do see a halt message when playing is stopped on the sender though, so this could be used, but I’d like to understand first. How does this work for you ?

Actually I get a STOPPED with the signal catching added, when the object is deleted before exit.

Is the purpose of the patch to call alsa_close() just before exiting (I can think of simpler ways to do it then), or is it the intention to call alsa_close() when playing stops on the sender ?

The latter. The intention of this patch is to link the ALSA device state to the "PLAYING" and "STOPPED" state.

The current issue is that the ALSA device is never closed. Of course a quick solution would be to just close it on exit of the receiver. But, it would be ideal if the "PLAYING" and "STOPPED" are really indicating if the Sender is streaming audio (PLAYING) or not (STOPPED). For now, the ALSA device is opened by the Receiver even when the Sender is actually not playing, e.g. when MPD is idle. As you know, you can see this by the "silence buffer" messages.

Though this commit does not make it ideal, as the ALSA device is opened though the Sender may not be playing anything, I’m fine with it. For now :smile:

What I still don’t understand is that I don’t see STOPPED messages, so the patch really does nothing before the process exits. The mod is then much too complicated for what it does? I’m just looking for the best approach for closing alsa when we don’t use it, so trying to understand fully.

Um, I was kind of expecting that "PLAYING" and "STOPPED" are indicating if actually audio frames are streamed by the Sender or not. Apparently, it is not the case, as "STOPPED" is only called if the Receiver is closed.

If, for example, the Songcast Sender is shutdown, I would expect that all Songcast Receivers are getting the signal that the audio stream is STOPPED, so they can close the audio device. Maybe, they should get a DISCONNECT, too. Furthermore, if the Sender playback is stopped, I would expect that all Receivers are notified that playback has stopped. This patch is based on this expectation. This does not mean that I know what should be expected based on the Songcast or OpenHome protocol. You’re much more involved than me.

Actually I seem to never get the STOPPED state until the receiver object is deleted (just before program exit). So I don’t think that this change is doing any good.

As far as I can see, there is no reliable signalling on the songcast stream. The only possible approach would be to detect that we are not getting new data in alsadirect.cpp, and close the driver until we do get data or get killed.

I am trying to understand the openhome libraries. For now, I figured that PLAYING and STOPPED are invoked when using the interactive keys: https://github.com/medoc92/sc2mpd/blob/master/sc2src/sc2mpd.cpp#L575-L581.

When using sc2mpd with ohPlayer I noticed that if the Playlist service is paused or stopped, the halt flag is set in the audio message. Maybe this information can be used to open/close the audio device?