General > Developers
MPD integration
tschak909:
Have you made a device in C++ yet? I would do that, before making anything else, so you can understand the API that we have fully. Why are you avoiding this?
-Thom
david_a_dawson:
--- Quote from: tschak909 on January 07, 2014, 04:41:00 pm ---Have you made a device in C++ yet? I would do that, before making anything else, so you can understand the API that we have fully. Why are you avoiding this?
-Thom
--- End quote ---
:-)
I have done some experiments with C++ devices yes. I do understand, mostly, the API and how it maps to the device definition and message passing, I did a fair amount of research to understand it all while building the java dce library.
On why I did that, and why I'm proposing python now? A few answers are possible.
I love to experiment and fiddle, re-implementing something is a nice way for me to understand how something works, so I enjoy the play time.
The potentially most contentious one is that C++ has a relatively higher barrier to entry as compared to java, python and ruby on a language level. The ruby integration is fairly basic, single threaded and unsuitable for building full devices.
The java dce lib isn't really suitable for much as it turns out, as the java environment is just too decoupled from any kind of automation for it to be worth it.
Python has quite tight integration via its C/C++ modules, so it is feasible to use it to write some real devices.
After all that though, the real answer is that mopidy is written in python. Any extensions to it will also be in python. Adding a DCE interface to it would be one of, write a seperate DCE device to manage it, or write a DCE layer within it. Having a dce device in it would mean interfacing C++ and python.
That's it. 'avoiding', no, interested in the challenge, yes.
Marie.O:
A Python DCE lib would probably a nice addition to the LinuxMCE stable of libs.
david_a_dawson:
After a little playing, I wonder if I could ask a little advice on how to lay out the various bits.
So, my ideal world.
I'd like to have an MPD server for each user in the system and have the audio from that routed to whichever speakers they choose.
Control for MPD can be via the normal MPD interface/ clients for now without any issue, ideally this could then be embedded into the orbiters and web interface, but that isn't something I'd like to tackle quite yet.
The audio handling/ routing is something I'm not sure about.
I have a few sqeezeslaves running that work well for LMCE based radio, I'd like to push the audio from mopidy through those too. Any suggestions on where I should start looking to implement that?
Also, after thinking a little more, it kind of feels like there would only be a single device in charge of spinning up the mopidy servers, probably on the core. Then the audio would be streamed from there. Does that sound reasonable?
In that case, it may not be necessary for the mopidy servers to be DCE devices at all and renders the python/ DCE .. discussion.. somewhat moot.
Lastly, should I upgrade or develop this in a 12.04 env.
tschak909:
Any new features go into the development trunk, which right now is 12.04, full stop. 10.04 will not receive any new features, and you shouldn't develop any new features on it.
Since this is a media plugin and player pair, you'll need to develop these in C++, full stop. No, don't argue. You'll have to, because the media plugins need to have access to class pointers of the other plugins in the router memory space to do infrastructure work.
-Thom
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version