2010-09-04, 15:04
Hello
Maybe I'm in the wrong place to ask or XBMC is wrong software to start from, but here goes anyway...
I'm trying to setup a multi-head system based on a pattern of use that includes (i) primarily audio use (in the first instance);
(ii) the audio being streamed is available to at least one renderer in HQ i.e. 24bit/96KHz FLAC and available to other renderers in lower formats;
(iii) an assumption that the HQ audio renderer should really be headless (because they're way over there on a stack hifi gear hooked up to a DAC via optical out and I'm over here working on my laptop listening to the music coming out of the hifi speakers);
(iv) and therefore I need a UPnP remote with which to control my HQ audio renderer.
So (i) and (ii) are easy, I've currently settled on MediaTomb as a UPnP server which happily lives a long way t'other side of my network, transcodes on the fly, is easy to setup and manage, etc., with a NAS providing the storage.
(iii) seems to be a problem, and to a degree (iv). All the renderers I can find are not intended for use in the way I want to use it (or at least not in a sensible way - the resources used by a renderer outputting to a DAC should be entirely suited to a low-end fanless box, but not while running a shiny but, in context, entirely unnecessary GUI. All a renderer needs to do is take commands and play the media it is told too.
I have a working solution to (iv), eezUPnP. Still a few bugs to tweak but given how young it is, functioning way above anything else I could make run on a PC. Could do with album art support, maybe some sort of search facility; and a nice sound visualiser would be a neat trick on a remote...
But XBMC could be perfect, if there was a way to separate the GUI control point from the renderer. A <xbmc --headless> mode for the renderer and the ability to remote control from another XBMC instance the headless instance (or any other UPnP renderer).
Please tell me this can already be done or is in the pipeline so I can stop banging my head on the Internet looking for an answer...
Maybe I'm in the wrong place to ask or XBMC is wrong software to start from, but here goes anyway...
I'm trying to setup a multi-head system based on a pattern of use that includes (i) primarily audio use (in the first instance);
(ii) the audio being streamed is available to at least one renderer in HQ i.e. 24bit/96KHz FLAC and available to other renderers in lower formats;
(iii) an assumption that the HQ audio renderer should really be headless (because they're way over there on a stack hifi gear hooked up to a DAC via optical out and I'm over here working on my laptop listening to the music coming out of the hifi speakers);
(iv) and therefore I need a UPnP remote with which to control my HQ audio renderer.
So (i) and (ii) are easy, I've currently settled on MediaTomb as a UPnP server which happily lives a long way t'other side of my network, transcodes on the fly, is easy to setup and manage, etc., with a NAS providing the storage.
(iii) seems to be a problem, and to a degree (iv). All the renderers I can find are not intended for use in the way I want to use it (or at least not in a sensible way - the resources used by a renderer outputting to a DAC should be entirely suited to a low-end fanless box, but not while running a shiny but, in context, entirely unnecessary GUI. All a renderer needs to do is take commands and play the media it is told too.
I have a working solution to (iv), eezUPnP. Still a few bugs to tweak but given how young it is, functioning way above anything else I could make run on a PC. Could do with album art support, maybe some sort of search facility; and a nice sound visualiser would be a neat trick on a remote...
But XBMC could be perfect, if there was a way to separate the GUI control point from the renderer. A <xbmc --headless> mode for the renderer and the ability to remote control from another XBMC instance the headless instance (or any other UPnP renderer).
Please tell me this can already be done or is in the pipeline so I can stop banging my head on the Internet looking for an answer...
