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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
