I've just opened a discussion about that here =
https://forum.videolan.org/viewtopic.php?f=7&t=115414
Currently JRiver Media Center allows crossovers.
Actually there are two different implementations.
1. rely on the internal JRiver crossover features (they are quite limited)
2. ask JRiver to duplicate the audio into 2 x 2 channels, then routing each channel to a particular external convolver (long FIR filters)
A few diyAudio members like Pano are using the external convolver method, and seem happy with that.
I have the impression that JRiver can deliver the stereo audio to JACK.
The stereo audio appears thus as ASIO stream, to be processed by any VST!
Thus, any VST dealing with crossover, speaker management, convolver, etc ... would be applicable!
Using Flowstone, I can design any kind of audio crossover in a matter of minutes. Flowstone can generate a VST, or an .EXE
I feel that an .EXE compiled by Flowstone, could handle the ASIO stream coming from JRiver + JACK, without needing a VST host. Is this true?
Now come difficulties associated to the VST format.
- Can a VST output audio through HDMI?
- Can a VST run on ARM Android?
Any info welcome.
Currently XBMC has a new AudioEngine under the hood (ActiveAE), with XBMC developers FernetMenta and Fritsch very busy, debugging it.
There is a youTube presentation about ActiveAE here :
http://www.youtube.com/watch?v=_78YxAXQyBg
XBMC relies on ffmpeg for decoding the audio/video stream.
That's the main, crucial point. XBMC only configures ffmpeg, and as return XBMC grabs audio (and video), like any ffmpeg Sink needs to.
On XBMC forum, on 2013-11-22, Fritsch had the idea of enabling the use of a different Sink, a custom Sink.
Looks seductive, but it gets complicated knowing that such custom Sink needs to output the stream, physically on HDMI, motherboard, USB audio attachment.
On XBMC forum, on 2013-11-23, Fritsch (possibly alarmed by JRiver Media Player advanced DSP features) had the generous idea of allowing an "in between stage", acting as Sink for the ffmpeg stream, altering the audio, then reinjecting the altered audio into the standard XBMC Sink. This way XBMC gets in charge of routing the altered audio, physically on HDMI, motherboard, USB audio attachment.
On XBMC forum, on 2013-11-23, FernetMenta announced that "Audio engine has an architecture as well with a processing stage. Moving audio processing into a sink violates the rules of this architecture." FernetMenta adds "What we currently have is flexible enough to do this. No need for any quick hacks." IMO, such assertion from FernetMenta clashes against Fritsch generous idea. And, take notice that FernetMenta never substantiates the claim that "What we currently have is flexible enough to do this".
On XBMC forum, on 2013-11-23, jjd-uk realized that XBMC Audio Configuration Panel would require a supplementary field for choosing between "no in between stage" and "select in between stage". He went against adding such selector : "If a DSP interface is introduced then in my view we shouldn't be polluting the standard audio settings GUI with what is a specialised function that will likely have a limited userbase".
I'm not optimistic about XBMC.
1) I fear that all XBMC divas/gurus will keep refusing one more selector in XBMC Audio Configuration Panel for naming the optional "in between stage". Which means they will not fill the gap separating them from JRiver Media Player. Actually, the idea of an "in between stage" is not trivial. There are N audio channels in, and M audio channels out. A possibility is to let XBMC scan each "in between stage" file header for knowing how to connect the ins and the outs.
2) I still don't know how to render that "in between stage" both Windows and Android compatible, like generating one source code, then compiling it for Windows, then compiling it for Android. One need to provide the same multiPlatform/multiOS deployment scheme as XBMC.
The XBMC case illustrates that a cluster of divas en gurus, systematically using less than 5 lines of text for exposing, submitting or replying, has a close to zero productivity, whatever they may appear sympathetic and enthusiasts. Could be they suffer from the NIH syndrome (Not Invented Here). Anyway, like most Media Player, they rely on ffmpeg as blackbox (invented where, haha ??!!), and surely they got many issues with audio, as ActiveAE is now the second (or third) audio architecture they tried (invented where, haha ??!!). On one hand, thus, they deliver the ugly impression that they don't care about audio, that they don't care about supporting diyAudio extensions, but on the other hand, they are currently extremely busy with audio, intensively debugging ActiveAE. Any analyst would say that it is the right moment for XBMC developers to grab knowledge from the external world, like from diyAudio, and to listen to future-proof requirements.
To date, VLC has provided the most encouraging answers.
On VLC forum, on 2013-11-24, Jean-Baptiste Kempf replied :
- Yes, you can do an audio filter in VLC, including resampling, upmixing, downmixing and everything.
- An open-source filter in C or C++ will work on ALL versions of VLC.
I have thus asked :
- if he could recommend working examples of VLC plugins acting as audio filter
- if there is an API, documentation, tutorial about creating an open-source filter in VLC
As I wrote above, I encourage you to follow the discussion taking place here :
https://forum.videolan.org/viewtopic.php?f=7&t=115414
Sorry for the long post, but IMO one need to expose things, one for all, for knowing about what it goes.
