Open YeonV opened 3 years ago
stijnvdb88
commented
3 years ago Hi!
Web is out of the scope of this project unfortunately - Snap.Net only runs on Windows, Android and iOS for the moment. Snapcast itself does have a web implementation though (https://github.com/badaix/snapweb), it might be worth opening a feature request there :)
Broadcasting for android is already on my todo-list! See https://github.com/stijnvdb88/Snap.Net/issues/7
stijnvdb88
commented
3 years ago Update: this feature is mostly working now, just a few kinks to iron out. Please have a quick look and let me know if it's all working as expected!
https://github.com/stijnvdb88/Snap.Net/releases/tag/v0.25.0.1
The broadcasting feature has 2 major caveats to be aware of:
Chaphasilor
commented
3 years ago Just got around to test this out, and it works really well!
I'm having some trouble with my Snapcast server, at some point it stops accepting broadcast streams (the stream stays idle and nothing is transmitted to the clients), and this caused some issues with the app too.
Starting to broadcast "worked" (snapserver didn't play anything, but that was to be expected), however when trying to stop the broadcast the app got stuck, but didn't crash.
Here's a picture of the frozen app:
You can still see the ripple effect from pressing the "Stop Broadcast" button, the ripple never disappeared until force-closing the app through Android settings.
The "Stop" button inside the persistent notification also didn't do anything :)
Aside from that, everything worked great!
Both media and microphone broadcast worked, and you can even mute the music volume on the device and it still broadcasts playing music, etc. (on Android 11 at least).
Given that the device's music/media volume doesn't affect the volume of the broadcast, it would be nice to have a way to manually control that volume.
One way would be to add the broadcast volume as a "Cast" audio stream, like other apps are doing it (e.g. when connected to YouTube TV, etc.). This would offer easy and native volume control, hopefully without too much work :)
Anyway, thanks a ton for your efforts!
If there's anything else you want me to test, just tell me :D
stijnvdb88
commented
3 years ago Thanks! That issue with the server is new to me - you're saying it randomly occurs after x amount of time? Do you see the same/similar when you use the Snap.Net broadcast feature? Next time it happens you can also try connecting manually through the Snap.Net.Broadcast.exe command line app, it might spit out some useful errors (be sure to close/disconnect all broadcast clients first though, multiple broadcasting clients will definitely make it go haywire)
Chaphasilor
commented
3 years ago Well I don't think it's an issue with Snap.Net. It looks like the snapserver either doesn't accept or ignores the incoming TCP stream. Other input sources, like pipes (e.g. for Mopidy) still work just fine.
I only use the TCP input for Snap.Net's broadcast, and that stops working if the server ignores the stream :)
I might try using the binary to get some logs...
YeonV
commented
3 years ago Yooo broadcasting was not working for me until i swapped to microphone. When setting mode to Media, no sound is incoming. (although it sees the active stream)
Tried with BubbleUpnp and android integrated music app (spotify ofc didnt work, but i thought local mp3 from phone would be fine)
airmusic + magiskmodule + spotify does work via airplay+shareport as pipe in snap-server. really looking forward to replace that messy airmusic with the clean snap.net app
Chaphasilor
commented
2 years ago @YeonV what's your ROM / Android version? can you try with the SoundCloud app? that one works for me...
Chaphasilor
commented
2 years ago @stijnvdb88 Any plans for adding support for the Metadata API to the broadcast implementations on windows and especially android? :D
stijnvdb88
commented
2 years ago @Chaphasilor I've given it some thought, but I'm not sure it's possible tbh. There are two major issues with getting audio metadata from a broadcast stream to snapserver:
We literally don't actually know what's playing :-D the way broadcast works, is we simply forward whatever audio's being sent to our sound card to snapserver instead (just raw pcm, nothing else). we don't even know which software is sending that audio, let alone artist/song. The audio isn't necessarily even music - you could be broadcasting the sound of a movie you're watching, or talking through a microphone. This goes for both PC and Android - while Android does have the concept of "now playing" metadata which apps can set, I can't find any way of querying/reading from it.
Even if we did somehow figure out what's playing, we don't have any way of reporting this to snapserver. The scriptControl plug-in system queries the stream instead of the other way around. Eg. snapserver asks the mpd plugin, which asks the MPD server. A Spotify plug-in would ask Spotify, using your credentials and Connect device name. The tcp stream however barely even knows which device is sending the audio (pc/android/something else), and there's no protocol for exchanging metadata atm. In other words, it wouldn't know who to ask, or how to ask.
Do you have any thoughts on these? The second problem might be solvable if snapserver would allow us to report metadata across the json-rpc api, but if I'm reading this code right, "metadata" isn't a property you can set that way. That's a decision that makes sense imo, it would be backwards for the server to expect a client to report what the server is playing.
Chaphasilor
commented
2 years ago stijnvdb88
commented
2 years ago you're completely right, opening our own socket on the plugin script would work for that second issue!
The first one is trickier than you'd think though, the problem isn't exactly that there's no API to access this data, it's that the data simply isn't there: iirc the concept of "now playing" didn't even exist in Windows until a few years ago. There is some API for reading "now playing" metadata, but it doesn't look like most media players actually report to it, which makes it useless for what we're trying to do here. I've tried VLC, MPC and even Windows Media Player but none of them seem to be sending their metadata to this system. You can try it yourself by downloading a release from this demo project, for me it's only showing things like Youtube videos that were left open in Chrome - not output people are likely to be broadcasting. Does it show anything useful on your end?
For Android, maybe MediaSessionManager.getActiveSessions does what we're looking for. On that platform at least we know the data is there since you can plainly see the "now playing" info on the lock screen, it's just a matter of figuring out how to get to it.
Chaphasilor
commented
2 years ago Well yeah, if the data isn't available (e.g. pre-Win10), there's nothing to show. But I would suggest we use the new media session stuff used by browsers and some music players.
I myself use the YT Music and Spotify PWAs (web-based) extensively, and they all show up there.
VLC and WinMediaPlayer are pretty outdated feature-wise, and mpc is probably not bothering with any system APIs at all.
But them not using available APIs (yet) isn't our problem :)
Also, there might be plugins for VLC and mpc that add support, I know there is one for MusicBee. So if someone wants to use that feature of Snap.net, they probably can...
If you want to implement custom metadata detection, go ahead, but I don't think it's worth it 😅
YeonV
commented
2 years ago @YeonV what's your ROM / Android version? can you try with the SoundCloud app? that one works for me... @Chaphasilor Android 10 - LinageOS 17.1 Thanks for the tip, i will try
SoundCloud app: Mircophone works, media not :/
Chaphasilor
commented
2 years ago @stijnvdb88 so it's been a few months and I've actually been using this feature extensively. Here are my thoughts:
The core functionality is pretty solid. Connectivity is good (slightly more dropouts compared to e.g. Mopidy, but that's to be expected due to the additional hop). Battery drain is high, but tolerable while at home. I can leave the broadcast running over night without a problem.
The issues I mentioned above about the app hanging up when stopping the broadcast is still there. What I've gained since then is that the issue occurs when my phone loses connection to my snapserver (e.g. when WiFi disconnects). In this case, the server hangs up:
As mentioned before, changing the volume really is a pain, because the broadcast is unaffected by the system volume.
This means that you always need to open the Snap.Net app and use the volume slider there. Adding a "remote volume control" slider (as seen in Yatse, YouTube TV) would be the nicest option in my opinion.
I think the focus right now should be point 3, as it's the greatest pain-point.
The rest of the features worked well enough for me on both Android 11 and 12 that I can live with the current version for a while.
What do you think?
The Broadcast-Functionality is AWESOME!!!
would be nice to have it also available on Android and/or Web:
Android: https://developer.android.com/guide/topics/media/av-capture Web: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia
Example of WebAudio including input device selection: https://github.com/YeonV/wled-manager/blob/v0.0.9/renderer/components/AudioContainer.jsx#L41-L65