It is likely that your problem comes from the different programming paradigm
between the two libraries. ICS is non-blocking (asynchronous) while the
other is blocking. It is possible that you don't follow the rules for
asynchronous programming and get problems... There are two very important
rules: 1) Never call directly or indirectly the message pump from one of the
component event and 2) never forget that all calls to methods - such as Send
- are merely requests and that you get control back immediately while your
request execute in the background.

If you follow the rules, everything will be OK. You can verify by yourself
that ICS components are capable of high speed communication with a huge
number of simultaneous connections, both client or server side. See the HTTP
and FTP client and server to convince yourself.

--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be




-----Message d'origine-----
De : twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] De la
part de robertoschler
Envoyé : mardi 7 février 2012 05:07
À : TWSOCKET
Objet : [twsocket] Problems with TWSocket and Skype

Hello,

A couple of years ago I tried using TWSocket with Skype to send audio back
and forth between my Delphi 6 application and the Skype client.  I never
could get it to work until I switched to the Indy components.

Since then I've used ICS in several applications they have always worked
great.  Now I have another application that interfaces with Skype and again
I am having trouble trying to get TWSocket to work with Skype.

My application acts as a middleman between an external WiFi webcam device
relaying audio from its microphone to Skype's input audio port and relaying
audio from Skype's output audio port to the webcam device's speaker.  I am
using ICS on both sides now.  TWSocket works just fine with the external
WiFi webcam, however, I can't make it work with Skype.  The audio going to
Skype is frequently "jamming up" whereby the buffered byte count rises
quickly for short durations, enough to make the audio stream going to Skype
unusable (calling TWSocket.Send).  The socket receiving audio from Skype
receives about 11 to 20 data deliveries successfully and then just dies
(OnDataAvailable stops firing).  The connection stays open, but Skype stops
sending audio permanently.


Both sockets for the pair of connections are spawned by a listening socket.
The way you tell the Skype client to receive audio from your application is
to open a socket on a port number of your choice and Listen.  You then tell
Skype the port number you are using and Skype connects to you on that port.
The same goes for the socket you use send audio to Skype.  In both cases you
Listen and Skype connects to you on the given port.  The difference of
course being that you repeatedly handle OnDataAvailable() events on the
socket that is receiving audio from Skype, and repeatedly call Send() on the
socket that is sending audio to Skype.

I'd rather keep things ICS all around but I'm close to switching to Indy on
the Skype side.  I recently found out that Skype uses Indy for its Windows
clients.  I'm also aware that Indy uses a thread that blocks to do its work
as opposed to TWSocket which uses a message loop.

Can anyone speculate as to what about Indy's sockets are more compatible
with Skype than (at least for me) TWSocket sockets?  What could I try to
quickly fix this situation, perhaps by more closely emulating Indy's
behavior?

Thanks,
Robert
--
To unsubscribe or change your settings for TWSocket mailing list please goto
http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to