[M@yeulC]

And I added a very generic trial code for it using JSON RPC. It was based on zeromq which I tbh think we don't need for it, so one could make a PR based on mine but using TCP jsonrpc instead. Which would be awesome.

is this the your branch for that work? https://github.com/topfs2/xbmc/tree/zeromq

Everything contained within that single branch or?

Oooops, I just remember I never pushed it since I wanted to do more on it (check viability etc) before I made any noise
However, I can put it up as soon as I am near my home computer. I mostly started on the abstraction, highlighting were it could be hooked in. And I got it working sending audio from kodi to another process through it. The other way around didnt work (possibly due to me doing something wrong with AE).

So in general I think it would be a good starting point for this project, and there is still lots and lots to do (I didn't have time to investigate the actual latency calculations, which is needed for sending audio over eth or wifi). But it should be very doable I think. And a feature I would personally love to have in kodi

Thank you for pointing out your work. Yes, this could indeed be a good starting point, even though we may not need zeromq. The rest seems feasible, given enough time.

Edit: I'm reviewing the conversation and I may be missing why Bluetooth is being brought up. The proposal appears to be about sending over wifi as well.

It was only mentioned so that it is kept in mind just in case, so that if the implementation is properly abstracted then the code could perhaps be reused for these types of Bluetooth remotes too.

As far as I know, this kind of setup is already quite possible using bluez, if the media center has a bluetooth dongle.

[keith]

I know when Roku switched to having headphones support in the remote, their remotes went from being Bluetooth to Wifi-direct.

[Dark_Slayer]

Edit: I'm reviewing the conversation and I may be missing why Bluetooth is being brought up

It was only mentioned so that it is kept in mind just in case, so that if the implementation is properly abstracted then the code could perhaps be reused for these types of Bluetooth remotes too.

Not to speak for everyone, but I had mentioned Bluetooth for an entirely different reason

Kodi Bluetooth support may already be possible in a lot of ways, but WiFi is much more ubiquitous

My thoughts were if you have a new Bluetooth headset for your phone or tablet. The phone/tablet already handles a lot of Bluetooth device compatibility. This project would just get audio to the phone or tablet via WiFi. From the phone/tablet you typically have three options . . . headphone jack, bluetooth, and the internal speaker

That's how I thought it would expand bluetooth options, bit clearly there is more potential beyond that. WiFi audio alone would be amazing though

[topfs2]

The problem with Bluetooth and the audio profiles is that in the wild its generally very unidirectional. I.e. phones does not broadcast themselves as receivers of audio. And this is something that you can't just easily add. You need to rewrite the entire a2dp stack on top the rfcomm stack, and that's assuming that you don't need something more than that.

Its not a limitation of Bluetooth, its just not something that phones now support. Perhaps the next android or the next after that will add it and then it can be used instead. But for now I think we need to do this over WiFi to get the best possible ground for success.

[Tolriq]

And do not forget that most Kodi client do not have Bluetooth while they all have network connectivity

If they have Bluetooth they can already use applications to get audio.

Anyway not 100% related but if implementation can take care of also possibly send video it would be cool, as there is demand also for livetv / addons streaming.
While pure streaming of those without being played require more complex things as an other internal player to stream, having a way to stream what is currently playing with video would be cool.

And I suppose that if this is keep in mind even if not done in this project if the code is think to allow that it would be easy to add support later.

[topfs2]

And do not forget that most Kodi client do not have Bluetooth while they all have network connectivity

If they have Bluetooth they can already use applications to get audio.

Anyway not 100% related but if implementation can take care of also possibly send video it would be cool, as there is demand also for livetv / addons streaming.
While pure streaming of those without being played require more complex things as an other internal player to stream, having a way to stream what is currently playing with video would be cool.

And I suppose that if this is keep in mind even if not done in this project if the code is think to allow that it would be easy to add support later.

Yeah video could be interesting also, however I think it is better to do that as a seperate project. Our audio handling is far easier to follow, due to the cleanup with AE. Also it feels immediately more useful

If you send video you most probably want audio too, then a more generic transcode is probably better.

[natethomas]

Yeah video could be interesting also, however I think it is better to do that as a seperate project. Our audio handling is far easier to follow, due to the cleanup with AE. Also it feels immediately more useful

Yup. This remains a summer project for a single student. Asking for the moon probably isn't the best idea.

[mkortstiege]

While we're at it. Complete rewrite in HTML5 Hah ..

[Paxxi]

Can't this be implemented with upnp? The remote would act as a renderer and kodi as the controller and server. Not sure how it would work with syncing the playback though.

One benefit of using upnp is that it would make the feature usable with a lot of stuff besides our remotes.

[Tolriq]

Upnp does not work over internet Upnp is bad

Upnp is badly supported by most things todays.

Upnp should die in fire.

[natethomas]

Upnp does not work over internet Upnp is bad

Upnp is badly supported by most things todays.

Upnp should die in fire.

Not sure why support over the internet would be important?

Beyond that, I tenuously agree upnp doesn't make a ton of sense, if only because that'd just add another layer to trying to get video and audio synched that doesn't need to be there. At a guess most UPnP receivers would fail on audio synching pretty much immediately if they weren't expecting the need, resulting in a terrible user experience.

[Tolriq]

Upnp does not work over internet Upnp is bad

Upnp is badly supported by most things todays.

Upnp should die in fire.

Not sure why support over the internet would be important?

Beyond that, I tenuously agree upnp doesn't make a ton of sense, if only because that'd just add another layer to trying to get video and audio synched that doesn't need to be there. At a guess most UPnP receivers would fail on audio synching pretty much immediately if they weren't expecting the need, resulting in a terrible user experience.

Not for audio to remote for now playing

But streaming over internet is a very very high demand feature for Kodi.

[natethomas]

Not for audio to remote for now playing

But streaming over internet is a very very high demand feature for Kodi.

Alright, then I'd guess not super relevant to this idea. For GSOC students, keeping the scope as narrow as possible is really important.

[AchimTuran]

Hi @ll,

the idea with a WiFi sink is very awesome.

@M@yeulC
I don't know if you have seen our ADSP-System, but if you implement it as a AESink I think it would be possible to do audio signal processing at the server side and stream the samples through the WiFi client.
Also a multizone audio setup is possible.
Or with my adsp.xconvolver addon to do 3D audio through headphones. This would be really great, because the calculation is still at server side and the client could be a low budget device (Raspbery Pi, Android Phone,...).

[topfs2]

Upnp has been used successfully with pulseaudio before, so that could also be a possible path.http://askubuntu.com/questions/187086/how-do-i-set-up-live-audio-streams-to-a-dlna-compliant-device

Personally I think that doing it in JSON RPC is probably easier. And someone could duplicate the code to do it for upnp too.