24 Jul
2014
24 Jul
'14
2:03 p.m.
Hi Ffanci,
Thanks for all of that - some excellent food for thought there.
Another idea that's occurred to me is to use a Linux virtual machine (under
VMware Player) on my Windows machine: that seems to open up possibilities,
and removes the whole cross-platform hassle. I'll have to see, but
generating the audio locally may even then become a possibility, and all
the latency issues would then go away.
So, I have some fiddling around to do, but it looks like I'm getting
somewhere. May well use OpenVPN somewhere in that setup, too - we'll see.
Cheers,
Nikhil.
On Thu, 24 Jul 2014, F. Silvain wrote:
Nikhil Nair, Jul 23 2014:
Hey Nikhil,
I've only dabbled with it once or twice. FWIW:
...
2. Send audio via Jack and a streamer (probably
DarkIce) to an Icecast2
server; then use a media player such as WinAmp or MPlayer. The problem
here is buffering: 10-20 seconds of latency just isn't acceptable for the
realtime aspects of the project, and I don't know if there's a way to get a
media player to do unbuffered playback (a quick Google search seemed to
indicate not).
I managed latencies of 1-5 seconds, if I remember correctly.
Basically
tweaking the encoding options. Unfortunately I can't find my personal XML
config files. But I pulled all that from the icecast2 and ices/darkice
manuals. If you choose this, search for Jörn Nettingsmeier, Linux Audio
Conference and Karl Heiss in conjunction with icecast. They've done very
useful and skilled work on this!
3. Use netJACK1 to play audio direct from JACK
(that's the only one of the
3 networked-JACK solutions mentioned on the JACK website that's recommended
for use over a WAN). Unfortunately, once I dug into this, it looks like
the assumption is that the audio will be played on a Linux box: there
doesn't seem to be any provision for having the Windows machine as the one
doing the audio playing. I did have a quick look at netJACK2, but that
seems to assume the two machines are on the same LAN - you don't even
specify the IP address to connect to!
If you can find JACK2 under windows, you can
use a VPN tunnel. Openvpn isn't
too difficult under Linux. I've heard, that it isn't too bad setting it up
under windows either.
My last experience is, that you will need closely matching JACK versions,
since the streaming codec had a few incompatible changes over time.
...
Tunneling through a forwarded port (using ssh)
may help in some aspects,
but I'm not sure. AT least, it adds an extra set of possibilities, as do
VPNs.
Depending on your detailed specs, you can use SSH tunneling to send MIDI
data
from the Linux machine using a windows synthesizer. That removes streaming
the audio and reducs latency compared to most of the methods mentioned above.
I tried it between Linux machines on different networks using the ALSA
sequencer system and a tunnelled port for aseqnet. Latency was less than a
second. There are other network MIDI frameworks, which might be better suited
to interact with foreign operating systems.
Here's an untested idea: if you have a webserver installed on your machine or
another way to access the system in realtime, you could try encoding your
audio to a named FIFO or pipe (mkfifo) and simply access that FIFO. It will
look like a file and be accessible like a file. Possible issues: you might
not catch enough data at a time to receive meaningful info. Encoded audio is
sent in packages. There are important blocksizes to behold. Or something like
it. The FIFO might not yield the data in such a way, that you can read it
over the network. -- Hm, basically all the issues, for which streaming
applications have been written. :)
Good luck and better answers!
...
Ta-ta
----
Ffanci
* Internet: http://freeshell.de/~silvain