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

Add UPnP compatibility #194

Open
aboldakov opened this issue Jan 24, 2023 · 1 comment
Open

Add UPnP compatibility #194

aboldakov opened this issue Jan 24, 2023 · 1 comment

Comments

@aboldakov
Copy link

aboldakov commented Jan 24, 2023

Scream Audio is the only one stable and near_zero_latency virtual audio adapter for Windows (I've tried almost every)
But it uses a proprietary protocol and can be used only with custom build audiophile streamers (like RaspberyPi or BeagleBoneBlack).

There are lots of TOTL network streamers that accepts UPnP traffic as a UPnP renderers
while Scream already have an unicast ability, so sending signal to specific renderer looks quite possible

There are some repos with UPnP solutions https://github.com/topics/upnp-renderer
I don't understand that much at a tech side.
But it would be great to be able to Scream all the audio traffic from PC to an UPnP renderer.

I'm ready to donate a little (some hundreds of bucks)

@duncanthrax
Copy link
Owner

Thanks for the offer of donations, but I see little chance of this working.

  • I already implented RTP support in a (outdated) branch. It did work, but there's added CPU burn due to the byte reordering. Also, RTP receiver can't handle the fact that Scream will stop the stream when there is no audio playing. Implementing silence transfer in Scream is complicated, because it is not driven by its own timer loop, but the data pump from the Windows Sound Subsystem.
  • UPnP is more than just media formats, it defines rendezvous mechanisms for sources and renderers. In the kernel, this would be hard to implement. A userspace daemon could do that, and then send the Unicast target to the kernel driver. Still, I'm not inclined to code that. And even if I would, we still would need to support some standard media format, which would have to be PCM, since you would not want to do codec transforms inside kernel space, without hardware helpers.

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