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