Recently I have started attempting to replace an existing sip client with freeswitch. In doing so I have started looking more towards portaudio. My goal is to add some robustness to portaudio to make it better suited to being used by sip clients. Some of the features I have currently worked to implement: *Event generation for call holding and resuming *Ability to switch input/output devices during calls with live audio going on (useful for say speakerphone support) *Ability to switch both the indev and outdev at once rather than separately (time savings) *Ability to keep the audio stream initialized rather than each time a call is made/ device is rang (time savings) *Only init codecs during load / config reload rather than on audio stream init (time savings) *Ability to call play (for sounds) with active calls going on Most of the improvements so far have been to make portaudio a bit faster at doing things and less restricted than previously coded. Most changes have been made through additional configuration variables so out of the box portaudio will not function any differently than currently. My request for input is on next steps and warnings. Right now portaudio keeps track of two streams, the call audio stream and the ring audio stream (and both are inited on demand only accept with my always active stream change). I was thinking of taking the always active streams to a slightly higher level: I am thinking about moving to have it keep track of an arbitrary number of streams, a linked list of streams it is keeping track of with no more than one stream per input/output pair. This would allow for initing a device prior to use to allow for near instant use of that stream. This would remove the small delay that still exists (under 1 second currently I would estimate) when say switching on the speaker phone. Or allow for very quick playing of audio on a specific device. Aside from the speed increases in stream switching this would allow for you to play audio on a device that isnt currently the primary audio device. While I do not plan to take it this far currently, it would actually allow for a much easier time of handling multiple calls on different devices at the same time. The other way to go is to look towards trying to speed up initing streams more, there are some yields in the code that look like safety things that may be possible to remove without negative affects. Also I looked at the last merge of portaudio from upstream into trunk (end of 2007) and the changes that were made back then. The good news is there were not actually a lot of base code changes and most of them have actually been merged into upstream now so updating to the latest may not be a very hard thing to do. This is in part to see if it helps with the audio quality issues that people of portaudio seem to report as it certainly is not something you want in your client. If anyone has any input into the current state of portaudio or purposed changes please let me know. In addition if anyone has input into getting better call quality out of PA that would be extremely advantageous, as other than updating to trunk I doubt my changes will result in much of a quality improvement. I am specifically also interested if anyone knows of any of the reasons some of the safeguards that are there are in place, some of which I don't see a technical reason for them to be there unless there is funnyness in libportaudio itself (which certainly could be and may be partially resolved with updating to the changes from the last 3 years). If anyone knows any stress testing etc that presented issues for PA previously that would be helpful. I am working with PA in windows, do have a linux box I will do some limited testing on, but overall if you just can test various changes let me know as that will be helpful too as I believe removing some of the safety steps may not present as an issue right away. I could also add a "faster" option to portaudio config that would result in the optimizations rather than just removing them completely. ~Mitch