Closed highgain86j closed 7 years ago
Yep, that's already in my todo-list to allow the user to choose the alsa ouput to use. It was also mentioned in #3 7th comment (currently the latest comment in #3 ). As to make vban_receptor natively jackd or PulseAudio enabled, well, that's another story, but if the demand is growing, why not.
Well, because the Banana on Windows is capable of sending outputs to ASIO interfaces, jackd slave running on Windows (with JackRouter ASIO enabled) could potentially do things similar to those possibly achieved by making the above enhancements. This ASIO-based method has not been tested with my own hands, yet also has potentials to allow transmission/reception of 96kHz/24bit formats (or higher) as well. I think that the main reason for which people would want to choose Banana over jackd on Windows is mostly because the earlier provides the implementation of virtual sound device to accept any sound output from a given Windows host. I'm not saying jackd-capability of _vbanreceptor won't be popular. Instead, I am just saying this because I would like that people here understand actual values of discussions and improvements made. IMO, unnecessary or non-super-urgent of tasks should not keep the developers unnecessarily busy.
I just commited support for output alsa device selection. However, I keep this issue open and change the title to keep track of the idea to implement direct jackd support into vban_receptor.
@quiniouben Appreciations to your attitude and intention.
Jackd support is not yet implemented but I just commited support for pulseaudio, opening the door for multiple possible backends.
It took me a while, but here it is, jack support. Beware, I made it auto connect to first jack interfaces. If it is annoying for most, I can remove or make it as an option.
As I am using the built-binary with jackd2, the process uses (or must use) PulseAudio Jack Sink in order to get its output over to the sound device. The problem so far is, because PulseAudio Jack Sink mixes down all inputs to it, output from each instance of the _vbanreceptor (if/when running multiple instances) cannot be identified. If there were a command-line option to allow users to specify the sound interface through which the instance would output, that opens doors to running multiple instances of _vbanreceptor (for multiple connections with multiple hosts), and sending output to different jack-inputs using _jackinput, hence allowing _jackmixer be used in the setup. It's not super-urgent, but would be a neat enhancement if implemented. The best is _vbanreceptor becomes jackd-capable, but I guess that's asking for too much.