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
According to LMS Command Line Interface documentation, it is possible to send an input source selection command from LMS to the Transporter hardware player:
Transporter Digital Inputs
Transporter Digital Inputs are handled as remote streams, with a URL starting with source: followed by aes-ebu, bnc-spdif, toslink or rca-spdif.
To set Transporter to the TOSLINK input, use <playerid> playlist play source:toslink
When set to a digital input, Transporter reports the URL scheme above to the various path, url or status queries.
With squeezelite, it would be very beneficial to have a similar behaviour, for example to command Alsamixer to unmute the line-input of the soundcard. Or to turn on a GPIO, or run an external script with LIRC sending IR signals etc...
The use case for this would be to be able to switch to the speakers other line input audio sources local to the device. Eg. you could build a soundbar-like device, where you wire the sound coming from your TV through the device running squeezelite (just like you would do with Transporter). And then you could simply choose through LMS standard methods activation of Line-In, or a relay or whatever.
Currently, if I run with -d all=info all I see in the console when trying to play source:toslink is:
Would be useful to support any string after the source: keyword, not only aes-ebu, bnc-spdif, toslink or rca-spdif, but not sure if that's possible (depends on slimproto capability).
As a first step maybe it would be enough to have a command line option to pass a pair of parameters like: -T <sourcestring>:<scriptfilename> where sourcestring could be the part coming after source: and scriptfilename could be the script to run (similar to -S).
So in the example above we could have -T toslink:~/do_something.sh to run ~/do_something.sh when LMS asks to play source:toslink.
And when reporting back to the various path, url or status queries, just return sourcestring.
Something like -T <sourcestring1>:<scriptfilename1>,<sourcestringN>:<scriptfilenameN> would allow us to define multiple source selection commands.
The text was updated successfully, but these errors were encountered:
According to LMS Command Line Interface documentation, it is possible to send an input source selection command from LMS to the Transporter hardware player:
With squeezelite, it would be very beneficial to have a similar behaviour, for example to command Alsamixer to unmute the line-input of the soundcard. Or to turn on a GPIO, or run an external script with LIRC sending IR signals etc...
The use case for this would be to be able to switch to the speakers other line input audio sources local to the device. Eg. you could build a soundbar-like device, where you wire the sound coming from your TV through the device running squeezelite (just like you would do with Transporter). And then you could simply choose through LMS standard methods activation of Line-In, or a relay or whatever.
Currently, if I run with
-d all=info
all I see in the console when trying to playsource:toslink
is:Would be useful to support any string after the
source:
keyword, not onlyaes-ebu
,bnc-spdif
,toslink
orrca-spdif
, but not sure if that's possible (depends on slimproto capability).As a first step maybe it would be enough to have a command line option to pass a pair of parameters like:
-T <sourcestring>:<scriptfilename>
wheresourcestring
could be the part coming aftersource:
andscriptfilename
could be the script to run (similar to-S
).So in the example above we could have
-T toslink:~/do_something.sh
to run~/do_something.sh
when LMS asks to playsource:toslink
.And when reporting back to the various path, url or status queries, just return
sourcestring
.Something like
-T <sourcestring1>:<scriptfilename1>,<sourcestringN>:<scriptfilenameN>
would allow us to define multiple source selection commands.The text was updated successfully, but these errors were encountered: