[DUG] Reference counting

[Kyley Harris]

> wanted the audio engine to be separate from the application which
> controls it.  So I have 2 apps which needed fast communication, since
> it's providing VU meter data and elapsed times etc continuously 20 times
> a second.  I don't think TCP would handle that well.

;) I Think you should test. TCP runs as fast as your network card. so  
around 10mb per second
on a 100mb card.

The following code runs at around 5,500 iteratations a second as a ping  
returning same
quantity of data, not 20.... As I said, its not TCP thats slow, its the  
programmers who implement
stuff on top of it.

procedure TForm1.BitBtn1Click(Sender: TObject);
var
   i:integer;
   l:TLIst;
   c:cardinal;

begin
   IdTCPClient1.Host := 'localhost';
   IdTCPClient1.Port := 11000;
   IdTCPClient1.Connect;

   i := 0;
   c := GetTickCount;
   repeat

     IdTCPClient1.WriteLn('Testing one two three four five size seven  
eight');
     IdTCPClient1.ReadLn;
     Inc(i);
   until GetTickCount-c > 1000;
   showmessage(inttostr(i));


end;
On Fri, 25 Nov 2005 12:07:06 +1300, Ross Levis <ross at stationplaylist.com>  
wrote:

> TCP is definately useful.  I've implemented a remote utility to check
> the status of my player and provide some control and details of what's
> playing etc, but I decided to use the memory sharing facility because I
> wanted the audio engine to be separate from the application which
> controls it.  So I have 2 apps which needed fast communication, since
> it's providing VU meter data and elapsed times etc continuously 20 times
> a second.  I don't think TCP would handle that well.
>
> This system allows users to install an update to the controlling
> application without stopping play, assuming the audio engine doesn't
> need updating as well.  This is useful since it is designed for radio
> broadcasting.
>
> Ross.