I have (foolishly) decided that the right way to listen to podcasts through my Squeezebox is to hack together a ChromeCast Audio controller plugin. Presumably this would also let me cast other sources were I so inclined.
The ChromeCast device is connected to the (Mac) server's audio input and a modified version of the WavInput plugin is feeding data from a build of sox reading from CoreAudio and piping that data as a Slim::Player::Pipeline. So far so good, but the apparent duration of the track is 0, and the playback offset just keeps counting up.
Next I got brave and wired up a Python child process and some toy IPC using the pychromecast library. Now when the pipeline starts a "play" is sent to the ChromeCast and when it stops a "pause" is sent. canDoAction for "pause" returns false, because my reading is that "pause" means "server stops reading from the pipe", not "can the remote endpoint pause and send the server a stream of zeros". Corrections welcome.
A little more plumbing and getMetadataFor is returning track/album/info fetched from the python child, but duration is ignored _unless_ I set it on the song in getNextTrack. However the duration isn't helpful because it's the real duration, but the current offset is wrong.
There's a lot of questions elided in the above (is this a isRepeatingStream?, etc.), but the basics are there. However, before I decide to take this any further I realize I need to answer a core question: Is there a way to push playback external state into the server? Or must the server always control the state of the stream?
Some examples:
- When playback starts I may already be midway through a track, can I force the time (but not byte) offset in the UI?
- At every getMetadataFor there's a chance the play/pause state, or the time offset will have been changed externally via the casting device (or even another cast controller app). I have all this state available, but its not clear to me that i can force the server into the expected state. Can I tell the server the offset changed or the playback state changed without actually trying to tell the server to play or pause? In this scenario LMS is a passive listener, its not really in control.
- I can actually notify on state changes on the device, can I run state updates then? Or must I wait for the next getMetadataFor()?
- a canDoAction() for "rew" seems to want to be able to set the seek offset to zero itself, but the ChromeCast already has its own meaning for skip back that varies by the casting app. Is there a way to turn the rew button click into just the ChromeCast command and let it handle recomputing the seek offset?
- By the same token a skip forward (canDoAction() "stop"?) appears to want to trigger the getNextTrack() plumbing, but again all I really need is to send the skip forward command and let the ChromeCast handle it.
Any insight appreciated. I have the sense this isn't likely to work, or at least I can't find anything similar in plugins I've looked at, but I wanted to check before I gave up,
Axel
The ChromeCast device is connected to the (Mac) server's audio input and a modified version of the WavInput plugin is feeding data from a build of sox reading from CoreAudio and piping that data as a Slim::Player::Pipeline. So far so good, but the apparent duration of the track is 0, and the playback offset just keeps counting up.
Next I got brave and wired up a Python child process and some toy IPC using the pychromecast library. Now when the pipeline starts a "play" is sent to the ChromeCast and when it stops a "pause" is sent. canDoAction for "pause" returns false, because my reading is that "pause" means "server stops reading from the pipe", not "can the remote endpoint pause and send the server a stream of zeros". Corrections welcome.
A little more plumbing and getMetadataFor is returning track/album/info fetched from the python child, but duration is ignored _unless_ I set it on the song in getNextTrack. However the duration isn't helpful because it's the real duration, but the current offset is wrong.
There's a lot of questions elided in the above (is this a isRepeatingStream?, etc.), but the basics are there. However, before I decide to take this any further I realize I need to answer a core question: Is there a way to push playback external state into the server? Or must the server always control the state of the stream?
Some examples:
- When playback starts I may already be midway through a track, can I force the time (but not byte) offset in the UI?
- At every getMetadataFor there's a chance the play/pause state, or the time offset will have been changed externally via the casting device (or even another cast controller app). I have all this state available, but its not clear to me that i can force the server into the expected state. Can I tell the server the offset changed or the playback state changed without actually trying to tell the server to play or pause? In this scenario LMS is a passive listener, its not really in control.
- I can actually notify on state changes on the device, can I run state updates then? Or must I wait for the next getMetadataFor()?
- a canDoAction() for "rew" seems to want to be able to set the seek offset to zero itself, but the ChromeCast already has its own meaning for skip back that varies by the casting app. Is there a way to turn the rew button click into just the ChromeCast command and let it handle recomputing the seek offset?
- By the same token a skip forward (canDoAction() "stop"?) appears to want to trigger the getNextTrack() plumbing, but again all I really need is to send the skip forward command and let the ChromeCast handle it.
Any insight appreciated. I have the sense this isn't likely to work, or at least I can't find anything similar in plugins I've looked at, but I wanted to check before I gave up,
Axel