Issue 94

The upmpdcli sender appears active even if upmpdcli is not in sender mode, which can be confusing (because linking a receiver works but no playing occurs).

In fact, upmpdcli should report the Sender service if the service is implemented. For now, upmpdcli uses some kind of workaround to start the Sender service by setting the Source for a device. Furthermore, the Sender service is started as a separate device with its own UDN.

It would be more correct to enable/disable the Sender service by setting the Status variable as described in the [Linn docs](http://docs.linn.co.uk/wiki/index.php/Songcast_Sender) or the [OpenHome wiki](http://wiki.openhome.org/wiki/Av:Developer:SenderService).

upmpdcli uses the now unmaintained [1] [OhSongcast repo](https://github.com/openhome/ohSongcast), which implements a PC-based standalone Sender device [2].

Maybe we can port the current sender implementation to the Songcast code used in [ohPipeline repo](https://github.com/openhome/ohPipeline/tree/master/OpenHome/Av/Songcast).

I’ve [forked](https://github.com/joerg-krause/ohPipeline) the ohPipeline repo and added a CMake configuration to ease the build of the Songcast library. However, it will take me a while to understand the code.

https://github.com/openhome/ohSongcast/issues/4 https://github.com/openhome/ohSongcast/issues/5

Just as a note, there is a very big difference between how the Sender is implemented in upmpdcli and how it is implemented in an integrated device like a Linn device: upmpdcli does not have access to the audio stream (mpd owns this), so the Sender has to be an external process, meaning a separate device too.

The only way to go around this, without integrating the audio part inside upmpdcli, which I don’t want to do, would be to implement audio capture at the Alsa level: mpd would do its thing, upmpdcli would capture the audio and do the Sender thing.

This would also imply linking upmpdcli with the OpenHome libs, which I don’t think I want to do at all, so I think that the Sender is going to remain a separate device. By the way, the Windows and Mac Songcast apps are also Senders as separate devices, so I don’t see why this should be an issue.

The only thing really linking upmpdcli and the Sender is the trick of controlling the Sender through Renderer Source selections, which is really just this: a trick, but a very convenient one. Changing this would mean for example implementing a Web app for controlling the Sender.

I think that the only question is: should upmpdcli kill the Sender when its source is not one of the xxx-to-Songcast ones ?

We had another discussion going on the same subject actually: https://www.lesbonscomptes.com/upmpdcli/github-issues/upmpdcli-html/issue-83.html

I understand that mpd owns the audio stream (ALSA), but why does it mean that the Sender service has to belong to a separate UPnP device? Once upmpdcli restarts mpd with a new configuration the sender service could be started for the same UPnP device. It is not really an issue, just confusing…

From the Openhome wiki: > The Sender service indicates the presence of a Songcast sender and provides information concerning that sender. > If a device’s Product service reports an attribute source of type Sender, then that device is guaranteed to bear the Sender service. Alternatively, Songcast senders can be discovered independently of the Product service by simply searching for devices bearing the Sender service.

From my understanding it means that it is indeed possible to set a source of type Sender, though it is not documented elsewhere. I’ve opened an issue about this: https://github.com/openhome/ohNet/issues/29.

IMO, the Sender and the Receiver service should only be present if Songcast is activated, e.g. by setting the source type of the Product service to Sender or Receiver. As such, my answer to your only question would be: yes, upmpdcli should kill the Sender/Receiver service if its source type is not Sender/Receiver.

As things turned out "Sender" is a supported value of Attributes whereas "Receiver" is a supported value of the source type in SourceXml (as upmpdcli uses it).

To be honest, I am not sure about this anymore.

The practical constraint that we have is that the UPnP device which hosts the Sender UPnP service is implemented by OpenHome code inside the mpd2sc process. Being a separate process, it has to be a separate device (AFAIK). There are two things in mpd2sc: the UPnP control interface (device+service), and the Songcast code which deals with the audio stream.

I could experiment with killing mpd2sc when the source is not one PL-To-Songcast or Radio-To-Songcast. At worst, I’ll understand why I don’t currently do it :)

The current git code kills the aux mpd and sender process instead of keeping them around. Seems to work fine.

Thanks!

I wonder why you use an aux mpd instance. I am using [this](https://gist.github.com/joerg-krause/6661cfa54957ecb6c9332251d215440c) setup with an mpd configuration with two audio_outputs: alsa and fifo. This way, I can toggle mpd between these two outputs, e.g. by using mpc enable only FIFO.

At the start, I was not even aware that you could do this. There is one remaining reason, which is to avoid forcing the user to modify their mpd.conf for defining the fifo output (also I’m not sure if tthe dynamic switching was available in older versions ?)