|
a/doc/upmpdcli-manual.txt |
|
b/doc/upmpdcli-manual.txt |
|
... |
|
... |
173 |
but, for basic operation without a configuration file, a few of the main
|
173 |
but, for basic operation without a configuration file, a few of the main
|
174 |
parameters can be set on the
|
174 |
parameters can be set on the
|
175 |
xref:COMMAND-ENVIRON[command line or in the environment].
|
175 |
xref:COMMAND-ENVIRON[command line or in the environment].
|
176 |
|
176 |
|
177 |
However, a majority of parameters can only be set in the configuration
|
177 |
However, a majority of parameters can only be set in the configuration
|
178 |
file. This this is set set through the +-c+ command line option. The usual
|
178 |
file, which is designated with the +-c+ command line option. The usual
|
179 |
path is +/etc/upmpdcli.conf+
|
179 |
path is +/etc/upmpdcli.conf+
|
180 |
|
180 |
|
181 |
The configuration file has a simple `name = value` format.
|
181 |
The configuration file has a simple `name = value` format.
|
182 |
|
182 |
|
183 |
|
183 |
|
|
... |
|
... |
194 |
|
194 |
|
195 |
This section goes in a little more detail about miscellaneous aspects of
|
195 |
This section goes in a little more detail about miscellaneous aspects of
|
196 |
the Media Renderer, and describe a few of the most used configuration
|
196 |
the Media Renderer, and describe a few of the most used configuration
|
197 |
parameters. See the <<UPMPDCLI-CONFIG,configuration reference section>>
|
197 |
parameters. See the <<UPMPDCLI-CONFIG,configuration reference section>>
|
198 |
for more details (I would very much like to link each parameter to its
|
198 |
for more details (I would very much like to link each parameter to its
|
199 |
definition but Asciidoc won't let me do it...).
|
199 |
definition but Asciidoc won't let me do it, so they link to the top of the
|
|
|
200 |
appropriate section.).
|
200 |
|
201 |
|
201 |
If several instances of *upmpdcli* run on the same network, you will want
|
202 |
If several instances of *upmpdcli* run on the same network, you will want
|
202 |
to give them distinct names. The name which is displayed by most Control
|
203 |
to give them distinct names. The name which is displayed by most Control
|
203 |
Points can be set with the <<friendlyname,+friendlyname+>> configuration
|
204 |
Points can be set with the <<friendlyname,+friendlyname+>> configuration
|
204 |
parameter. Some Linn Control Points (e.g. Kazoo) use another value, set
|
205 |
parameter. Some Linn Control Points (e.g. Kazoo) use another value, set
|
|
... |
|
... |
208 |
host. However, there may be reasons to do otherwise, and the host name and
|
209 |
host. However, there may be reasons to do otherwise, and the host name and
|
209 |
port where mpd should be reached can be set with <<mpdhost,+mpdhost+>>,
|
210 |
port where mpd should be reached can be set with <<mpdhost,+mpdhost+>>,
|
210 |
and <<mpdhost,+mpdport+>>.
|
211 |
and <<mpdhost,+mpdport+>>.
|
211 |
|
212 |
|
212 |
The Upmpdcli Media Renderer has two active interfaces by default: UPnP AV
|
213 |
The Upmpdcli Media Renderer has two active interfaces by default: UPnP AV
|
213 |
and OpenHome. Only OpenHome control points can share the renderer, there
|
214 |
and OpenHome. Only OpenHome Control Points can share the renderer. If you
|
214 |
can be at most a single UPnP AV Control Point (and no OpenHome ones in this
|
215 |
use an UPnP AV Control Point, it must be the only one. This is not
|
215 |
case). This is not enforced, and misuse will result in miscellaneous
|
216 |
enforced, and misuse will result in miscellaneous weirdnesses. In some
|
216 |
weirdnesses. In some special situations, it may be useful to limit the
|
217 |
special situations, it may be useful to limit the interface to UPnP AV or
|
217 |
interface to UPnP AV or OpenHome only (or disable both), which can be done
|
218 |
OpenHome only (or disable both), which can be done with the
|
218 |
with the <<friendlyname,+openhome+>> and <<friendlyname,+upnpav+>> parameters.
|
219 |
<<friendlyname,+openhome+>> and <<friendlyname,+upnpav+>> parameters.
|
219 |
|
220 |
|
220 |
[[UPMPDCLI-RENDERER-FORMATS]]
|
221 |
[[UPMPDCLI-RENDERER-FORMATS]]
|
221 |
=== Audio formats
|
222 |
=== Audio formats
|
222 |
|
223 |
|
223 |
Upmpdcli can accept most audio formats supported by MPD, meaning about
|
224 |
Upmpdcli can accept most audio formats supported by MPD, meaning about
|
224 |
anything, including DSD.
|
225 |
anything, including DSD.
|
|
|
226 |
|
|
|
227 |
Upmpdcli normally checks that the format of a resource to be played is
|
|
|
228 |
compatible with what it thinks MPD can do. This check is sometimes
|
|
|
229 |
pessimistic and can be disabled by setting
|
|
|
230 |
<<friendlyname,+checkcontentformat+>> to 0.
|
225 |
|
231 |
|
226 |
You should know that MPD has difficulties with some formats _when accessed
|
232 |
You should know that MPD has difficulties with some formats _when accessed
|
227 |
through HTTP_ which is how the Media Server transfers the data.
|
233 |
through HTTP_ which is how the Media Server transfers the data.
|
228 |
|
234 |
|
229 |
Specifically, WAV and AIFF files, especially with samples wider than 16
|
235 |
Specifically, WAV and AIFF files, especially with samples wider than 16
|
230 |
bits are a frequent source of trouble (because they are little used and
|
236 |
bits are a frequent source of trouble (because they are little used and
|
231 |
little tested for streaming). Support will vary depending on the MPD
|
237 |
little tested for streaming). Support will vary depending on the MPD
|
232 |
versions and exactly what input plugins are configured (among *ffmpeg*,
|
238 |
versions and exactly what input plugins are configured (among *ffmpeg*,
|
233 |
*libaudiofile* and *libsndfile*). Often, the same files play just fine
|
239 |
*libaudiofile* and *libsndfile*). Often, the same files play just fine
|
234 |
locally, it's the configuration of HTTP access and file format which causes
|
240 |
locally, it's the combination of HTTP access and file format which causes
|
235 |
problems.
|
241 |
problems.
|
236 |
|
242 |
|
237 |
Raw PCM streams are another special case. The reason is that these streams
|
243 |
Raw PCM streams are another special case. The reason is that these streams
|
238 |
do not, by definition, carry metadata to define the exact format (sample
|
244 |
do not, by definition, carry metadata to define the exact format (sample
|
239 |
rate, bits per sample, number of channels, byte order). *upmpdcli* has no
|
245 |
rate, bits per sample, number of channels, byte order). *upmpdcli* has no
|
240 |
way to transfer these parameters to *MPD* (this is a limitation of the
|
246 |
way to transfer these parameters to *MPD* (this is a limitation of the
|
241 |
client protocol). The parameters can be transferred from the Media Server
|
247 |
client protocol). The parameters can be transferred from the Media Server
|
242 |
with the MIME type though.
|
248 |
to the player along with the MIME type though. In consequence, only recent
|
243 |
|
|
|
244 |
Recent versions of upmpdcli and MPD (0.20 and later) do support audio/L16,
|
249 |
versions of Upmpdcli and MPD (0.20 and later) do support audio/L16, but
|
245 |
but there are conditions on the Media Server (it must output the audio
|
250 |
not with any Media Server (it must output the audio formats
|
246 |
formats parameters with the MIME type). See this Github issue for more
|
251 |
parameters with the MIME type). See this Github issue for more details:
|
247 |
details:
|
|
|
248 |
https://github.com/medoc92/upmpdcli/issues/36#issuecomment-227761220
|
252 |
https://github.com/medoc92/upmpdcli/issues/36#issuecomment-227761220
|
249 |
|
253 |
|
250 |
In general, there are few reasons to use these linear formats, when FLAC
|
254 |
In general, there are few reasons to use these linear formats, when FLAC
|
251 |
will produce exactly the same bits, with less network load (which largely
|
255 |
will produce exactly the same bits, with less network load (which largely
|
252 |
compensates the small additional CPU load).
|
256 |
compensates the small additional CPU load).
|
|
... |
|
... |
263 |
This facility uses Python 2.x, which must be available on the system for
|
267 |
This facility uses Python 2.x, which must be available on the system for
|
264 |
the radio links to work.
|
268 |
the radio links to work.
|
265 |
|
269 |
|
266 |
Radio stations can be defined in the configuration (at the end because of
|
270 |
Radio stations can be defined in the configuration (at the end because of
|
267 |
the use of section indicators), or in in a separate file by setting the
|
271 |
the use of section indicators), or in in a separate file by setting the
|
268 |
+radiolist+ parameter in the main configuration.
|
272 |
<<ohproductroom,+radiolist+>> parameter in the main configuration.
|
269 |
Example entry:
|
273 |
Example entry:
|
270 |
|
274 |
|
271 |
----
|
275 |
----
|
272 |
[radio Radio Teddy]
|
276 |
[radio Radio Teddy]
|
273 |
url = http://opml.radiotime.com/Tune.ashx?id=s80044
|
277 |
url = http://opml.radiotime.com/Tune.ashx?id=s80044
|
|
... |
|
... |
280 |
icon. +artUrl+ is optional.
|
284 |
icon. +artUrl+ is optional.
|
281 |
|
285 |
|
282 |
Radio channels can be accessed by selecting the _Radio_ Source from an
|
286 |
Radio channels can be accessed by selecting the _Radio_ Source from an
|
283 |
OpenHome Control Point.
|
287 |
OpenHome Control Point.
|
284 |
|
288 |
|
285 |
Some radios (e.g. _radioparadise_) publish the album art for the currently
|
289 |
Some radios (e.g. link:https://www.radioparadise.com/rp_2.php?#[Radio
|
|
|
290 |
Paradise]) publish the album art for the currently playing title. The
|
286 |
playing title. The details vary. The +artScript+ parameter, if set, should
|
291 |
details vary. The +artScript+ parameter, if set, should point to an
|
287 |
point to an executable script which prints this dynamic art Uri to
|
292 |
executable script which prints this dynamic art Uri to stdout. The image
|
288 |
stdout. The image will supercede the radio logo, to be displayed by control
|
293 |
will supercede the radio logo, to be displayed by control points. Beware
|
289 |
points. Beware that the path to the script must be accessible by the
|
294 |
that the path to the script must be accessible by the _upmpdcli_ user,
|
290 |
_upmpdcli_ user, which may not be the case for your home. +/usr/local/bin+
|
295 |
which may not be the case for your home. +/usr/local/bin+ is your
|
291 |
is your friend. As a very rough example here follows a command which would
|
296 |
friend. As a very rough example here follows a command which would retrieve
|
292 |
retrieve the radioparadise uri (as long as they don't change their format,
|
297 |
the Radio Paradise URI (as long as they don't change their format, a proper
|
293 |
a proper approach would use an xml parser of course):
|
298 |
approach would use an XML parser of course):
|
294 |
|
299 |
|
295 |
curl -s http://radioparadise.com/xml/now.xml | \
|
300 |
curl -s http://radioparadise.com/xml/now.xml | \
|
296 |
grep '<coverart>' | sed -e 's/<coverart>//' -e 's!</coverart>!!'
|
301 |
grep '<coverart>' | sed -e 's/<coverart>//' -e 's!</coverart>!!'
|
297 |
|
302 |
|
298 |
|
303 |
|
299 |
[[UPMPDCLI-SONGCAST]]
|
304 |
[[UPMPDCLI-SONGCAST]]
|
300 |
== Upmpdcli and Songcast
|
305 |
== Upmpdcli and Songcast
|
301 |
|
306 |
|
302 |
Upmpdcli implements the Receiver UPnP service, and uses an auxiliary
|
307 |
Upmpdcli implements the Receiver UPnP service, and uses an auxiliary
|
303 |
process (*sc2mpd*) for transporting the audio data. *sc2mpd* is a slight
|
308 |
process (*sc2mpd*) for transporting the audio data. *sc2mpd* is based
|
304 |
modification of the sample program which comes with the Linn Songcast
|
309 |
on the sample program which comes with the Linn Songcast
|
305 |
OpenHome open source implementation
|
310 |
OpenHome open source implementation
|
306 |
|
311 |
|
307 |
*upmpdcli* can also manage a Sender subsystem, which is implemented by
|
312 |
Upmpdcli can also manage a Sender subsystem, which is implemented by using
|
308 |
using a separate *mpd* instance sending audio to an *mpd2sc* command (part
|
313 |
a separate *mpd* instance sending audio to an *mpd2sc* command (part of the
|
309 |
of the *sc2mpd* package). The latter is a modified version of the OpenHome
|
314 |
*sc2mpd* package). The latter is a modified version of the OpenHome
|
310 |
WavSender sample program. This allows playing the usual upmpdcli playlist
|
315 |
WavSender sample program. This allows playing the usual Upmpdcli playlist
|
311 |
or radio on several synchronized players, but also doing the same thing
|
316 |
or a a radio channel on several synchronized players, but also doing the
|
312 |
with a captured analog source (e.g. *arecord* output).
|
317 |
same thing with a captured analog source (e.g. *arecord* output).
|
313 |
|
318 |
|
314 |
NOTE: You should know that it is possible to control the Songcast Sender
|
319 |
NOTE: You should know that it is possible to control the Songcast Sender
|
315 |
from another local network PC to snoop on what you are listening (Radio or
|
320 |
from another local network PC to snoop on what you are listening (Radio or
|
316 |
Playlist). This is detectable from the Renderer state, but not obvious. In
|
321 |
Playlist). This is detectable from the Renderer state, but not obvious. In
|
317 |
any case, the playlist itself is public (there are no privacy provisions in
|
322 |
any case, the playlist itself is public (there are no privacy provisions in
|
318 |
UPnP), so this is probably not a major additional issue. The system will
|
323 |
UPnP), so this is probably not a major additional issue. The system will
|
319 |
not capture anything besides what *mpd*, or an explicitely setup additional
|
324 |
not capture anything besides what *mpd*, or an explicitely setup additional
|
320 |
source are playing (e.g. Skype phone conversations are out of reach).
|
325 |
source are playing (e.g. Skype phone conversations are out of reach).
|
321 |
|
326 |
|
322 |
[[UPMPDCLI-RECEIVER]]
|
327 |
[[UPMPDCLI-RECEIVER]]
|
323 |
=== Upmpdcli Receiver
|
328 |
=== Upmpdcli Songcast Receiver
|
324 |
|
329 |
|
325 |
*sc2mpd* can play the *Songcast* audio stream in two modes:
|
330 |
*sc2mpd* can play the *Songcast* audio stream in two modes:
|
326 |
|
331 |
|
327 |
- By offering a local HTTP interface (based on _libmicrohttpd_) from which
|
332 |
- By offering a local HTTP interface (based on _libmicrohttpd_) from which
|
328 |
*mpd* will play the stream.
|
333 |
*mpd* will play the stream.
|
|
... |
|
... |
342 |
advantage is that it needs no configuration. If you go the _alsa_ route,
|
347 |
advantage is that it needs no configuration. If you go the _alsa_ route,
|
343 |
you will need to set <<sclogfilename, +scalsadevice+>> in the
|
348 |
you will need to set <<sclogfilename, +scalsadevice+>> in the
|
344 |
configuration, but you probably had to set it in the MPD configuration too,
|
349 |
configuration, but you probably had to set it in the MPD configuration too,
|
345 |
so this may not be too much of an issue.
|
350 |
so this may not be too much of an issue.
|
346 |
|
351 |
|
347 |
When using _mpd_ more bufferisation occurs and there may be a significant
|
352 |
When using *mpd*, more bufferisation occurs and there may be a significant
|
348 |
delay (up to around 10 S) between the time when Songcast is activated
|
353 |
delay (up to around 10 S) between the time when Songcast is activated
|
349 |
and the time sound appears.
|
354 |
and the time sound appears.
|
350 |
|
355 |
|
351 |
NOTE: When using _mpd_, from a Mac (24 bits audio) you need an
|
356 |
NOTE: When using _mpd_, from a Mac (24 bits audio) you need an
|
352 |
appropriately configured and recent MPD version (usually configured with
|
357 |
appropriately configured and recent MPD version (usually configured with
|
|
... |
|
... |
381 |
|
386 |
|
382 |
WARNING: There is *no software volume control* for the *upmpdcli* Songcast
|
387 |
WARNING: There is *no software volume control* for the *upmpdcli* Songcast
|
383 |
Receivers for now: use either a local mixer or the little round things on
|
388 |
Receivers for now: use either a local mixer or the little round things on
|
384 |
the pre-amps. Set the volume low when experimenting !
|
389 |
the pre-amps. Set the volume low when experimenting !
|
385 |
|
390 |
|
386 |
NOTE: Songcast can be use IP multicast for lower load on the network when
|
391 |
NOTE: Songcast can use IP multicast for lower load on the network when
|
387 |
playing on several hosts. Unfortunately, multicast WIFI don't mix well in
|
392 |
playing on several hosts. Unfortunately, multicast WIFI don't mix well in
|
388 |
many cases. If you have wireless Receivers experiencing sound drop issues,
|
393 |
many cases. If you have wireless Receivers experiencing sound drop issues,
|
389 |
try selecting unicast in the Songcast advanced configuration panel on the
|
394 |
try selecting unicast in the Songcast advanced configuration panel on the
|
390 |
desktop.
|
395 |
desktop.
|
391 |
|
396 |
|
392 |
[[UPMPDCLI-SENDER]]
|
397 |
[[UPMPDCLI-SENDER]]
|
393 |
=== Upmpdcli Sender
|
398 |
=== Upmpdcli Songcast Sender
|
394 |
|
399 |
|
395 |
Upmpdcli Sender mode allows you to broadcast the Playlist or Radio source
|
400 |
Upmpdcli Sender mode allows you to broadcast the Playlist or Radio source
|
396 |
(or the output of any process which can write to a Fifo, e.g. *arecord*) to
|
401 |
(or the output of any process which can write to a Fifo, e.g. *arecord*) to
|
397 |
other Songcast Receivers. The local *upmpdcli* plays through its Receiver
|
402 |
other Songcast Receivers. The local *upmpdcli* plays through its Receiver
|
398 |
too, in order to achieve good synchronisation. Unlike the Songcast
|
403 |
too, in order to achieve good synchronisation. Unlike the Songcast
|
|
... |
|
... |
776 |
== Annex: Songcast installation walkthrough
|
781 |
== Annex: Songcast installation walkthrough
|
777 |
|
782 |
|
778 |
If you want to play from a Mac or Windows machine, install the
|
783 |
If you want to play from a Mac or Windows machine, install the
|
779 |
link:http://www.linn.co.uk/software#songcast[Songcast application]
|
784 |
link:http://www.linn.co.uk/software#songcast[Songcast application]
|
780 |
|
785 |
|
781 |
NOTE: Not all Windows Songcast versions work well with upmpdcli. Lately
|
786 |
NOTE: Not all http://oss.linn.co.uk/Releases/Songcast/Davaar/[Songcast
|
782 |
I've had good luck with
|
787 |
capture application versions] work well with upmpdcli. Lately (03-2017),
|
783 |
http://oss.linn.co.uk/Releases/Songcast/Davaar/Songcast_4.4.190_win.exe[4.4.190]
|
788 |
the latest version (4.8.535) seems to work fine. In the past, I've had good
|
784 |
but not with the 4.5 ones (it's possible to get them to work with
|
789 |
luck with 4.4.190 but not with the 4.5 ones (it is possible to get them to
|
785 |
*upmpdcli* from the *upplay* control panel, but the Windows app claims that
|
790 |
work with *upmpdcli* from the *upplay* control panel, but the Windows app
|
786 |
the *upmpdcli* receiver is unavailable.).
|
791 |
claims that the *upmpdcli* receiver is unavailable.).
|
787 |
|
792 |
|
788 |
I could not get IP multicast to work with WIFI Receivers (the sound drops
|
793 |
I could not get IP multicast to work with WIFI Receivers (the sound drops
|
789 |
constantly).
|
794 |
constantly).
|
790 |
|
795 |
|
791 |
There are well-known problems with multicast and WIFI (see for example
|
796 |
There are well-known problems with multicast and WIFI (see for example
|