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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Thu Jul 24 04:15:01 2014
This archive was generated by hypermail 2.1.8 : Thu Jul 24 2014 - 04:15:01 EEST