Menu
▾
▴
linuxsampler-devel
|
From: Tobias E. <t.e...@gm...> - 2004-01-09 18:19:10
|
Hi guys, I've followed the project for a couple of month now and I was always interested in doing some work for this. I think someone mentioned that one of the goals of LS was the idea of having a rack of Linux- based samplers running and use them from remote by their favorite sequencer-program. I thought this was a pretty cool idea and would like to offer to implement some kind of Win32-support for this. My idea is the following: I have already written a generic ASIO-driver for the Windows-Plattform (www.asio2ks.de) and I thought about including some network-streaming-code, so this asio-driver would have the "real" audio-ports from underlying soundcard and have "virtual" ports which are fed over IP/UDP/RTP from LS. I think the local network should provide for low enough latency for this... So if you have a sequencer like Cubase, you would define the "virtual" ports as inputs into the cubase-mixer and the "real" ports as output for monitoring to the monitor- boxes... What do you guys think about this? Tobias PS.: Obviously there would be the need to implement a virtual soundcard for ALSA as well - but perhaps someone already developed such a beast ;-) |
|
From: <be...@ga...> - 2004-01-09 22:12:33
|
Excellent Tobias !
That's exactly what future professional studio users will need.
That you already wrote an ASIO driver is very very valuable.
I'd opt for UDP for the transmission protocol.
(without retransmission since in local networks
the packet loss ratio is basically zero, and retransmission would kill
latency).
Ok perhaps for offline track bouncing using a TCP socket
would be handy (for the paranoid that fears to loose one packet
out of 10million packets transmitted).
But for now I think UDP is the way to go.
Regarding synchronizing with the windows machine.
The AudioIO class in LinuxSampler contains code to output audio,
in the network case instead of outputting audio you send out an
UDP packet that contains as much data as you would send to the soundcard.
But there is a problem: in the case of audio the soundcard blocks while
in the case of using the UDP sending routine the packet gets out immediately
and we need LinuxSampler wait for the windows box acknowledging the packet
since we must send out at a rate which matches the samplerate of the
windows soundcard.
I think the easiest to way to achieve synchronization is:
LinuxSampler:
writeAudio(data) {
wait_for_sync_packet_from_windows_box();
send_audio_packet_to_windows_box(data);
}
Windows box (ASIO driver) {
send_sync_packet_to_linuxsampler_box();
wait_for_audio_packet_from_linuxsampler_box();
write received data to ASIO buffer
}
The sync packet is very short and does not need to carry a special payload.
It's just to "wake up" LinuxSampler.
Perhaps on the windows receiving end we need to buffer more than one
packet to avoid audio dropouts. Please make this configurable
on the Windows side.
But on the linuxsampler sending side no buffering is needed, one packet is fully
ok, just listen for MIDI-in events, process audio and send out UDP packet.
Just start experiment with it by modifying the AudioIO, I'm sure
you will come up with interesting results !
cheers,
Benno
http://www.linuxsampler.org
Scrive Tobias Erichsen <t.e...@gm...>:
> Hi guys,
>
> I've followed the project for a couple of month now
> and I was always interested in doing some work for
> this. I think someone mentioned that one of the
> goals of LS was the idea of having a rack of Linux-
> based samplers running and use them from remote
> by their favorite sequencer-program.
>
> I thought this was a pretty cool idea and would like
> to offer to implement some kind of Win32-support for
> this.
>
> My idea is the following:
>
> I have already written a generic ASIO-driver for the
> Windows-Plattform (www.asio2ks.de) and I thought about
> including some network-streaming-code, so this asio-driver
> would have the "real" audio-ports from underlying
> soundcard and have "virtual" ports which are fed over
> IP/UDP/RTP from LS. I think the local network should
> provide for low enough latency for this...
>
> So if you have a sequencer like Cubase, you would define
> the "virtual" ports as inputs into the cubase-mixer and
> the "real" ports as output for monitoring to the monitor-
> boxes...
>
> What do you guys think about this?
>
> Tobias
>
> PS.:
> Obviously there would be the need to implement a
> virtual soundcard for ALSA as well - but perhaps
> someone already developed such a beast ;-)
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
-------------------------------------------------
This mail sent through http://www.gardena.net
|
|
From: Christian S. <chr...@ep...> - 2004-01-09 23:22:18
|
Es geschah am Freitag, 9. Januar 2004 23:12 als be...@ga... schrieb:
> Windows box (ASIO driver) {
>
> send_sync_packet_to_linuxsampler_box();
> wait_for_audio_packet_from_linuxsampler_box();
> write received data to ASIO buffer
> }
Multi threaded of course and buffered stream
> > Tobias
> >
> > PS.:
> > Obviously there would be the need to implement a
> > virtual soundcard for ALSA as well - but perhaps
> > someone already developed such a beast ;-)
I think a JACK client that implements the network protocol would be a better
idea. And btw. MIDI over ethernet is also planned for LS and there's already
a standard IEEE network protocol defined. The problem for Windows side is
that there's only one free client so far - DMIDI - and that has only support
for receiving, not for sending MIDI messages so far AFAIK. Or has that
changed meanwhile? Could you also imagine to extend that client? I guess this
would be welcome by many Windows users. The DMIDI client registers just as a
normal MIDI port on the Windows system, you can select IP and port address
with a graphical configuration frontend and you would be able to use a rack
of LinuxSampler boxes and access them in e.g. in Cubase as they would be
normal MIDI devices.
I'm of course also looking forward to your results!
CU
Christian
|
|
From: Mark K. <mar...@co...> - 2004-01-09 23:29:45
|
On Fri, 2004-01-09 at 15:17, Christian Schoenebeck wrote: > I think a JACK client that implements the network protocol would be a better > idea. There is a new Jack client written by Bob Ham for doing Jack over 1394 also. I haven't had a chance to test it, but with more bandwidth and guaranteed delivery times 1394 could offer something here also. It would be nice to actually send MIDI requests to LS and be able to return audio over the same cable in a very deterministic way. Anyway, fun to think about... Cheers, Mark |
|
From: <be...@ga...> - 2004-01-10 11:47:29
|
While 1394 is nice and gives some real time guarantees it has the drawback that it's harder to buy long cables, switches build large networks etc. I guess such setups are much more expensive. If you dedicate ethernet to audio it is very reliable and except in some troublesome cases the packet loss ratio and high latencies are basically zero. Even with a cheap D-Link 8 port switch I achieve the full 100Mbit and constant 0.1-0.2 msec ping times between two linux boxes. The poor man's linuxsampler cluster is much more likely to use ethernet than firewire since it has a lower TCO. That said firewire will be handy too but for now let's put the main weight on ethernet. Indeed, 2004 will become an interesting sampling-year :-) cheers, Benno http://www.linuxsampler.org Scrive Mark Knecht <mar...@co...>: > On Fri, 2004-01-09 at 15:17, Christian Schoenebeck wrote: > > I think a JACK client that implements the network protocol would be a > better > > idea. > > There is a new Jack client written by Bob Ham for doing Jack over 1394 > also. I haven't had a chance to test it, but with more bandwidth and > guaranteed delivery times 1394 could offer something here also. It would > be nice to actually send MIDI requests to LS and be able to return audio > over the same cable in a very deterministic way. > > Anyway, fun to think about... > > Cheers, > Mark > ------------------------------------------------- This mail sent through http://www.gardena.net |
Thanks for helping keep SourceForge clean.
X