Thanks, I will definitely review the full commit history on the portaudio files. The regression is my worst fear, I don't have the boxes, test cases, or time to really test the aggressive changeset as best as properly should be. I think I will concentrate on ensuring as minimal as possible changes out of the box and add configuration options to enable some of the optimizations which should allow users looking for the boosts or additional functionality to enable it without the possible negative affects to existing users. Syncing with upstream however is something that probably should be aggressively tested and there isn't a good way to just make that optional. The good news is mod_portaudio and libportaudio are pretty separate so I believe that at worst there will be a patchset to bring libportaudio up to trunk if people desire to do that but trunk could remain out of date.<br>
<br>Thanks for the input!<br><br>~Mitch<br>PS. the reason for switching both indev and outdev at once was for speakerphone (where you switch both the input and output at the same time sequentially during an active call), originally I was doing blocking calls and the delay there was a bit annoying, seeing how most of the time taken was on opening the stream itself (which opens both input and output at once) having an api command to set them both effectively halved that time.<br>
<br><div class="gmail_quote">On Tue, Jun 1, 2010 at 2:43 PM, Andrew Thompson <span dir="ltr"><<a href="mailto:andrew@hijacked.us">andrew@hijacked.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Sun, May 30, 2010 at 03:09:33PM -0400, Mitch Capper wrote:<br>
> Recently I have started attempting to replace an existing sip client with<br>
> freeswitch. In doing so I have started looking more towards portaudio. My<br>
> goal is to add some robustness to portaudio to make it better suited to<br>
> being used by sip clients. Some of the features I have currently worked<br>
> to implement:<br>
><br>
> *Event generation for call holding and resuming<br>
> *Ability to switch input/output devices during calls with live audio going<br>
> on (useful for say speakerphone support)<br>
<br>
</div>These are both good ideas. I've definitely wanted to switch the devices<br>
during a call and not been able to.<br>
<div class="im"><br>
> *Ability to switch both the indev and outdev at once rather than separately<br>
> (time savings)<br>
<br>
</div>I'm not convinced this is really worth it, but it probably won't hurt<br>
anything.<br>
<div class="im"><br>
> *Ability to keep the audio stream initialized rather than each time a call<br>
> is made/ device is rang (time savings)<br>
> *Only init codecs during load / config reload rather than on audio stream<br>
> init (time savings)<br>
<br>
</div>I think these should be done with a lot of caution. I believe the first<br>
one used to be the cause but it caused some weird issues..?<br>
<div class="im"><br>
> *Ability to call play (for sounds) with active calls going on<br>
<br>
</div>Another good idea.<br>
<div><div></div><div class="h5">><br>
> Most of the improvements so far have been to make portaudio a bit faster at<br>
> doing things and less restricted than previously coded. Most changes have<br>
> been made through additional configuration variables so out of the box<br>
> portaudio will not function any differently than currently. My request for<br>
> input is on next steps and warnings.<br>
><br>
> Right now portaudio keeps track of two streams, the call audio stream and<br>
> the ring audio stream (and both are inited on demand only accept with my<br>
> always active stream change).<br>
><br>
> I was thinking of taking the always active streams to a slightly higher<br>
> level:<br>
> I am thinking about moving to have it keep track of an arbitrary number of<br>
> streams, a linked list of streams it is keeping track of with no more than<br>
> one stream per input/output pair. This would allow for initing a device<br>
> prior to use to allow for near instant use of that stream. This would<br>
> remove the small delay that still exists (under 1 second currently I would<br>
> estimate) when say switching on the speaker phone. Or allow for very quick<br>
> playing of audio on a specific device.<br>
> Aside from the speed increases in stream switching this would allow for you<br>
> to play audio on a device that isnt currently the primary audio device.<br>
> While I do not plan to take it this far currently, it would actually allow<br>
> for a much easier time of handling multiple calls on different devices at<br>
> the same time.<br>
><br>
> The other way to go is to look towards trying to speed up initing streams<br>
> more, there are some yields in the code that look like safety things that<br>
> may be possible to remove without negative affects.<br>
<br>
</div></div>The problem is, a lot of them are there for a reason. Dig into the<br>
commit logs (svn blame or git blame) and see *why* and *when* they were<br>
added. Don't assume that they're just there because of 'cargo cult<br>
programming', they were added for a reason.<br>
<div class="im">><br>
><br>
> Also I looked at the last merge of portaudio from upstream into trunk (end<br>
> of 2007) and the changes that were made back then. The good news is there<br>
> were not actually a lot of base code changes and most of them have actually<br>
> been merged into upstream now so updating to the latest may not be a very<br>
> hard thing to do. This is in part to see if it helps with the audio<br>
> quality issues that people of portaudio seem to report as it certainly is<br>
> not something you want in your client.<br>
<br>
</div>I believe I was behind the last sync with upstream (fix for FreeBSD). If<br>
you want to try running it with a newer portaudio, by all means try it,<br>
but TEST IT THOROUGHLY - this means linux/mac/windows and maybe even<br>
solaris. Making it better on windows but worse everywhere else will not<br>
make you popular.<br>
<div class="im"><br>
><br>
> If anyone has any input into the current state of portaudio or purposed<br>
> changes please let me know. In addition if anyone has input into getting<br>
> better call quality out of PA that would be extremely advantageous, as other<br>
> than updating to trunk I doubt my changes will result in much of a quality<br>
> improvement. I am specifically also interested if anyone knows of any of<br>
> the reasons some of the safeguards that are there are in place, some of<br>
> which I don't see a technical reason for them to be there unless there is<br>
> funnyness in libportaudio itself (which certainly could be and may be<br>
> partially resolved with updating to the changes from the last 3 years). If<br>
> anyone knows any stress testing etc that presented issues for PA previously<br>
> that would be helpful. I am working with PA in windows, do have a linux box<br>
> I will do some limited testing on, but overall if you just can test various<br>
> changes let me know as that will be helpful too as I believe removing some<br>
> of the safety steps may not present as an issue right away. I could also add<br>
> a "faster" option to portaudio config that would result in the optimizations<br>
> rather than just removing them completely.<br>
><br>
<br>
</div>I would definitely like to see some work on portaudio, but be aware that<br>
the module works as well as it does because we tested it in all sorts of<br>
crazy situations and make it work in the majority of them and that you<br>
don't want to add regressions just to pursue some mythical<br>
performance/quality goal.<br>
<br>
Just do some investigating on why things are the way they are before you<br>
get to hacking, so you know what to test for.<br>
<br>
Good luck,<br>
<font color="#888888"><br>
Andrew<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br>