Open Marekkon5 opened 4 years ago
It's a good idea.
Note for later: This may also be possible on iOS via AirPlay.
Any newer thoughts on cast support? AirPlay already works automatically in iOS when playing media with your plugin - its kind of built in. I would love cast support for Android (iOS is likely never going to have a bunch of folks asking for it). With casting to a Chromecast or Google Cast, there's a fair amount of development and I would be willing to test/support this effort if you decide to go this route. Thanks for your hard work on this and Audio Service!
There is a discussion and some code over on #248 . Doing it right will require some planning on the Android side, particularly since it may require collaboration with the audio_service plugin.
My priority at the moment however is getting the next release of audio_service out, then releasing #311 , then working on #97 , #147 , #329 and somewhat related #307 , which in turn depend on #334 .
While I'm focused on those things, the discussion on casting can continue. I think it would help for anyone who wants to contribute in some way to start analysing the requirements of casting on the Android side and work out a draft design spec for how we will modify just_audio and audio_service to achieve this goal.
Thanks for the replay and detailed roadmap. I may work on null safety and take a look at 248 in order to add any insights that I may have. I have implemented audio-only casting in my current app which I'm presently re-writing in Flutter - hence my request.
Thanks @franklink , your insights would definitely be helpful.
Is Airplay on iOS working? I am not able to play get the audio playing on the remote airplay target.
Is Airplay on iOS working? I am not able to play get the audio playing on the remote airplay target.
Yes, I just tested in my app running Audio_Service 0.17.0-nullsafety.0 and Just_Audio 0.7.1 and AirPlay displays targets and moves playback to target once selected. Pause/play works both in the iOS media center and when going through Just_Audio. I am using a Yamaha receiver as my target.
I'm currently working on a pure dart casting library called audio_cast which may be a better fit in @ryanheise's existing audio ecosystem from a long-term point of view.
The plugin will support Chromecast
via dart_chromecast, Airplay
via multicast_dns, and DLNA
via upnp. I am currently working on getting Chromecast
support ready while DLNA
is already implemented and working.
Similar to the federated plugin architecture everyone interested in contributing can write his own CastAdapter
.
If you are, comment on this issue and we can find a task for you to do.
Airplay
(through AirplayCastAdapter
)Chromecast
supportWhat do you think about the proposal?
Is Airplay on iOS working? I am not able to play get the audio playing on the remote airplay target.
Yes, I just tested in my app running Audio_Service 0.17.0-nullsafety.0 and Just_Audio 0.7.1 and AirPlay displays targets and moves playback to target once selected. Pause/play works both in the iOS media center and when going through Just_Audio. I am using a Yamaha receiver as my target.
Interesting, I am trying to Airplay to a AppleTV 4K, and playback seems to start from the phones perspective, but no sound is played from the tv and the play button on the phone becomes disabled.
I'm currently working on a pure dart casting library called audio_cast which may be a better fit in @ryanheise's existing audio ecosystem from a long-term point of view.
Awesome... This would definitely be the dream solution if it can be done as a separate plugin that slots into the ecosystem. On Android, how do you envisage handling an app's transition between a local player (e.g. just_audio) and the cast player? Do we remove the audio_service notification and replace it with the cast notification, or do we try to keep the audio_service notification and implement logic within the app to switch handling of the play/pause/etc callbacks to route to the cast player instead of the local player?
I'm currently working on a pure dart casting library called audio_cast which may be a better fit in @ryanheise's existing audio ecosystem from a long-term point of view.
I am very interested in the Chromecast part. How would that fit in the just_audio
/audio_service
ecosystem? I am very curious.
I tried to use flutter_video_cast
together with audio_service
and just_audio
, but it allows to play only one song.
I'm currently working on a pure dart casting library called audio_cast which may be a better fit in @ryanheise's existing audio ecosystem from a long-term point of view.
Awesome... This would definitely be the dream solution if it can be done as a separate plugin that slots into the ecosystem. On Android, how do you envisage handling an app's transition between a local player (e.g. just_audio) and the cast player? Do we remove the audio_service notification and replace it with the cast notification, or do we try to keep the audio_service notification and implement logic within the app to switch handling of the play/pause/etc callbacks to route to the cast player instead of the local player?
I would keep the notification by implementing a casting API within just_audio
and map callbacks to audio_cast
similar to how audio_session
is embedded while also being available as a standalone package.
What is your preference?
Not quite sure I understand the mechanics of this, since you didn't mention how audio_service fits in (this is where the notification is handled for on-device playback). But if we use the audio_service notification for on-device playback, to keep that notification going when switching to casting would seem to imply using the audio_service callbacks to control the cast player. Is that what you had in mind?
I'm currently working on a pure dart casting library called audio_cast which may be a better fit in @ryanheise's existing audio ecosystem from a long-term point of view.
I am very interested in the Chromecast part. How would that fit in the
just_audio
/audio_service
ecosystem? I am very curious.I tried to use
flutter_video_cast
together withaudio_service
andjust_audio
, but it allows to play only one song.
I have just added support for Chromecast devices.
As dart_chromecast
currently does not pass static analysis which would result in an [UNIDENTIFIED] release on pub.dev, the next version will probably be delayed but you can use the version on git.
Not quite sure I understand the mechanics of this, since you didn't mention how audio_service fits in (this is where the notification is handled for on-device playback). But if we use the audio_service notification for on-device playback, to keep that notification going when switching to casting would seem to imply using the audio_service callbacks to control the cast player. Is that what you had in mind?
Not quite sure if I understood your question but audio_service callbacks should definitely control the cast player while casting.
That sounds really promising, I had the impression from the discussion over at #248 that managing this transition between local and cast players might be a bit more complicated, but it's great to hear that your solution can be plugged in like this.
That sounds really promising, I had the impression from the discussion over at #248 that managing this transition between local and cast players might be a bit more complicated, but it's great to hear that your solution can be plugged in like this.
We need to make sure that the package reaches some sort of a stable milestone and is tested on various different platforms as just_audio is a flutter favorite and used by a lot of developers.
I have just added support for Chromecast devices.
As
dart_chromecast
currently does not pass static analysis which would result in an [UNIDENTIFIED] release on pub.dev, the next version will probably be delayed but you can use the version on git.
Oh nice. I have been experimenting with the code from this example. The problem I encountered was passing the CastSender
object (which is created when connecting) to the audio_service
entrypoint (which is a top level function). I will continue on Monday.
I had a look at your code and it looks like you can play only one song at a time, but I think extending to a playlist would be easy using:
_castSender.loadPlaylist(List<CastMedia> media, {bool append = false, bool forceNext = false})
I can try your package, if it make my code easier in my project, and the contribute to it if you like.
I'm currently working on a pure dart casting library called audio_cast which may be a better fit in @ryanheise's existing audio ecosystem from a long-term point of view.
The plugin will support
Chromecast
via dart_chromecast,Airplay
via multicast_dns, andDLNA
via upnp. I am currently working on gettingChromecast
support ready whileDLNA
is already implemented and working.Similar to the federated plugin architecture everyone interested in contributing can write his own
CastAdapter
.If you are, comment on this issue and we can find a task for you to do.
Tasks that can be done:
- [ ] Add documentation
- [ ] Migrate mp3_info to nullsafety (simple!)
- [ ] Migrate upnp to nullsafety
- [ ] Migrate dart_chromecast to nullsafety
- [ ] Add support for
Airplay
(throughAirplayCastAdapter
)- [ ] ~Add
Chromecast
support~ @peterscodeeWhat do you think about the proposal?
This is exactly what i need. Care to share details and status?
Please refer to YT music cast feature
Hello. Any updates? How I help with implementing this feature? I use just_audio + audio_service in projects in my work, maybe you help with links to how I implement it?
Also curious. Our current implementation combining audio_service
& flutter_video_cast
is feeling a bit rusty
I think audio_cast has promise (this was shared by @peterscodee above), so I would encourage people to take a look at it, create issues for anything that doesn't work, and consider poking around in the code yourself to see in what way you might be able to contribute given that these are all open source projects and contributions would most likely be welcome.
definitely prepared to contribute @ryanheise. thanks for response, will have a look
This is exactly what i need. Care to share details and status?
I have stopped actively working on the project, but I will support every pull request coming from the community if someone wants to move the project forward.
Looks like doing a null safety migration would be a good first step for someone to contribute.
Hi,
I am one of the maintainers of the audio_cast
package. We have now null safety support and are trying to test and improve the code and make it more stable. AirPlay support will take a bit more time as I want to focus on the stability of this package and iOS devices can use AirPlay right out of the box.
What good timing. I actually forked that project Sunday and found it was already null safe. I was, however, having trouble reliably getting notified about multiple devices on the network. Maybe that's something you are addressing?
Thanks
Yeah I just pushed a fix for that particular issue. The upnp device discoverer was in fact only discovering the first device
Not sure if either of these are relevant, but adding them here since I stumbled upon:
Not sure if either of these are relevant, but adding them here since I stumbled upon:
I've looked into flutter_cast_framework. It is a much more mature solution but it conflicts with audio_service due to mismatching base Android activity. The thing about this project is it actually uses Google's cast framework which might be advantageous in the long run as more features are needed. I'm fairly motivated because I've rewritten my app in Flutter and the only thing I'm missing in Android is cast support.
I've looked into flutter_cast_framework. It is a much more mature solution but it conflicts with audio_service due to mismatching base Android activity.
Can you provide more detail on what the mismatching base activity is? I think I have seen issues before where different flutter plugins can conflict possibly due to conflicting gradle dependencies.
@ryanheise Apologies as I may have spoken too soon. I do have it running after some work and it seems to be working well, but this is in tandem to your library. I'm testing to see what works and what doesn't, but it will take a lot of mapping on your part to integrate this level of native UI interaction. I'm going to keep working on the tandem integration for my own purposes, but I feel like this library offers so much more robustness and out-of-the-box UI elements that it may worth the effort.
Any developments here? Seems like @gianlucaparadise is putting some effort into https://github.com/gianlucaparadise/flutter_cast_framework
flutter_cast_framework doesn't seem to have a licence yet which would need to be sorted out before anyone can contribute to it or before anyone can "use it", for that matter, (and it isn't published on pub.dev yet, so you'd need to get it from git). But if it is indeed the most feature complete, I should check it out and investigate the reported build conflict.
About flutter_cast_framework
:
flutter_cast_framework
ready for your work, I can publish an alpha version. I may introduce breaking change in the future, though.Thanks @gianlucaparadise! seems licence is appearing in pub.dev. @franklink curious if there's been any progress? Is your work pushed and I can possibly contribute?
Thanks for the bump, I just checked and the license is indeed now sorted out and it is published on pub.dev.
Calling out to contributors, would anyone be interested in contributing an example in example/lib/example_cast.dart
to showcase the capabilities of flutter_cast_framework? I'll have a go if nobody volunteers first.
@gianlucaparadise I have been experimenting with flutter_cast_framework today (with my Chromecast) in preparation for writing an example for just_audio.
In the flutter_cast_framework example app, when clicking the Chromecast icon, it gets stuck in discovery with a progress dialog that never successfully finds any devices.
Is this something you have encountered?
Also just FYI, it didn't compile out of the box, and required me to bump the compileSdkVersion
to 31.
@ryanheise did you try on a physical device? As far as I know, the android emulator is not able to display the Chromecast devices. On the other hand, the iPhone Simulator can display Chromecast devices.
About the compileSdkVersion
, I guess version 30 was not working because the IDE didn't find the SDK on your machine.
By the way, if you prefer, you can open an issue on flutter_cast_framework repository and move the discussion there.
Haven't tried running flutter_cast_framework
lately. I'm pretty sure it discovers in iOS simulator.
Not in in Dart but maybe it helps to create an implementation for just_audio: https://gitlab.futo.org/videostreaming/grayjay/-/tree/master/app/src/main/java/com/futo/platformplayer/casting?ref_type=heads
Implements casting for Airplay, Chromecast and DLNA in kotlin.
Is your feature request related to a problem? Please describe. Not related to a problem
Describe the solution you'd like Google/Chrome Cast support. Function which can be called in Dart to retrieve all available devices to cast to, and 2 other functions to connect (and disconnect) on the remote devices.
Describe alternatives you've considered None
Additional context I am assuming that ExoPlayer would handle most of it: https://developers.google.com/cast/docs/android_sender/exoplayer
Thank you.