[LAU] Request for advice: remote Linux server playing audio on local Windows system

[Nikhil Nair]

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