On Tue, Jun 01, 2010 at 06:22:42PM -0400, Mitch Capper wrote:
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.
If bringing portaudio up to date breaks anything we SHOULD fix that anyway, unless they decided to redo the whole API or something. It does look like there's some worthwhile changes in there (maybe even dmix support for ALSA). The only thing that looks scary is that it seems they're using scons for building now, instead of make. If you manage to get the module working against trunk (and trunk building in-tree) that's probably a big step forwards.
Thanks for the input!
~Mitch 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.
That's fair, just make the API reasonable. Andrew