RE: [Linuxsampler-devel] Win32-Integration-Proposal

[<be...@ga...>]

Tobias you did reply only to me privately (by accident) so I'm forwarding 
it to the list.
List members, please when replying only reply to the list,
CCs to members that are on list are useless and will result in annoying 
duplicate mails :-)

Anyway a few thoughts:

since we face the MIDI over ethernet problem too.
Why not do both in one rush ?
I propose the following: since the windows box must send
the sync packet to wake up LS. That sync packet could contain the midi data
The bandwidth of a MIDI channel is usually 31250kbit/sec
which is about 3000bytes/sec, quite low for an ethernet network.
So assume we use 128 sample fragments. (but make it configurable of course)
at 44100Hz this means 44100/128 = 344 packets per second sent by LS to
the windows box and 344 sync packets sent from the windows box to LS.
The sync packet carries no payload and we can use it to transmit midi data.
So I'd say define a maximum number of MIDI bytes per sync packet value.
Eg 128. This means 128*344 a virtual midi channel with a bandwidth of 44KB/sec.
Which is ten times as high as standard MIDI.

So on the windows box we need to write a small midi driver that listens
to local midi events and puts them into the outgoing sync packet queue.
In the rare case where we achieve the maximum midi bytes per sync packet
 value, we can send the rest of the MIDI bytes with the next sync packet.
LS will simply parse the incoming midi bytes that came with the sync packet
and if there are incomplete MIDI messages (eg only the note on byte and
 pitch value but the velocity byte has not been transmitted yet), it will
simply let it sit in a local queue/fifo and parse it at the next cycle.
Its very simple.

Regarding ASIO:
I'm not sure if ASIO is the way to go, how about going directly VST ?
VST is supported by any professional application under Windows plus
it has builtin MIDI which means you don't need to write a MIDI driver
the plugin directly gets the MIDI events from the sequencer.
Plus the VST callback is called exactly ( process() ) for each audio
 fragment processed, wich makes the whole stuff even more simple.

Comments ?

cheers,
Benno
http://www.linuxsampler.org



Scrive Tobias Erichsen <t.e...@gm...>:

> 
> 
> > -----Original Message-----
> > From: lin...@li...
> > [mailto:lin...@li...]On Behalf Of
> > be...@ga...
> > Sent: Friday, January 09, 2004 11:13 PM
> > To: lin...@li...
> > Subject: Re: [Linuxsampler-devel] Win32-Integration-Proposal
> > 
> > 
> > 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.
> 
> I want to send the stuff using RTP which is based on UDP
> and is specifically used for audio & video transmission
> stuff...
> 
> > (without retransmission since in local networks
> > the packet loss ratio is basically zero, and retransmission would kill
> > latency).
> 
> That's right - at work we are doing Voip-stuff, which for the
> same reasons is using UDP/RTP because retransmissions are
> bad for realtime-data...
> 
> I thought that I would synchronize the stuff to the clock
> of the PC-soundcard, as obviously this is the one driving
> the sequencer as well... so whenever the soundcard on the
> pc finishes a block of audio-data, i will send a packet
> to the other side... which then would cause ls to send
> a new packet...
>  
> Tobias 
> 




-------------------------------------------------
This mail sent through http://www.gardena.net