Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a server mode for devices that are not renderers (SWYH feature parity) #39

Closed
instinctualjealousy opened this issue Apr 29, 2021 · 4 comments

Comments

@instinctualjealousy
Copy link

instinctualjealousy commented Apr 29, 2021

The original SWYH provides a server accessible by Media Players as well as the traditional Stream To/PlayTo mode of pushing to Renderers. When SWYH is running, the audio stream is also exposed as two "songs" for the different codecs the original SWYH supports, which any player can access (theoretically, as I'm having an issue with theirs, and I think it's an implementation issue).

This would be useful to me because of this, but it would be useful for situations where the target device does not support rendering at all. It'd make this project an even more complete replacement. Sorry for the trouble. (=

See also: "If the device is an UPnP/DLNA Media Player" section.

@dheijl
Copy link
Owner

dheijl commented Apr 29, 2021

swyh-rs already provides a web server for accessing the stream at http://{ip}:5901/stream/swyh.wav, so that you can define it as a "web radio stream" in your renderer in case it does not support DLNA "pushing".

You can even download this stream from a browser should you want to do so, and get a file called swyh.lpcm.

This has always been the case in swyh-rs, and is also documented in the Readme.

The streaming format is PCM/L16, optionally with a WAV header of inifinite length (the original SWYH does not have this WAV header option). The only difference here with SWYH is that I do not support transcoding the audio stream to MP3, and that I do not advertise swyh-rs as a DLNA renderer.

In the latest release the port number (default 5901) can be changed.

@instinctualjealousy
Copy link
Author

instinctualjealousy commented Apr 29, 2021

HTTP Live Streaming, right? That's listed under "If the device doesn’t support the DLNA" for the original SWYH. If it doesn't provide a device for the Xbox 360 connect to and expose the stream from, I don't think it'd be possible to connect it with this by itself. My usecase might just be too weird to be worth implementing this, as HTTP Live Streaming would probably cover the other 99% for most people.

If only MS didn't lock down media renderer mode to single task. I have no clue why they did that. It's a far more graceful way of doing it and would easily work with both SWYH's with no problems. The only reason I need these weird workarounds is because of that. I might see what I can rig up though.

Edit: I was able to pair it with foo_upnp by adding the HTTP stream URL to a playlist in foobar2000- the 360 is okay with the raw stream! foo_upnp has "playback stream capture" but it's way more latent and seems to reset in some way on track changes which can mess up the latency. Performance is great, stable and seems to be sub-second. Much better than the 360's renderer mode in latency too. Rad. Anyway, I'd rtfm next time!

@dheijl
Copy link
Owner

dheijl commented Apr 29, 2021

You could use the free VLC app to listen to the network media stream on the Xbox, using the WAV header option.
But I don't know about the "background music" possibilities using VLC, as I've never set eyes on a Xbox.

Edit: I forgot about the foobar2000 option, you're right!

@dheijl
Copy link
Owner

dheijl commented May 2, 2021

I assume it works for you now, so I'm closing this.

@dheijl dheijl closed this as completed May 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants