This discussion is a refreshing change from some recent topics. Constructive, respectful, not insulting. This is how it should be.
On Sun, Sep 6, 2015 at 2:41 AM, Ross Bencina <rossb-li...@audiomulch.com> wrote: > Hello Andrew, > > Thanks for your helpful feedback. Just to be clear: I maintain the PortAudio > core common code and some Windows host API codes. Many of the issues that > you've raised are for other platforms. In those cases I can only respond > with general comments. I will forward the specific issues to the PortAudio > list and make sure that they are ticketed. > > Your comments highlight a difference between your project and ours: you're > one guy, apparently with time and talent to do it all. PortAudio has had 30+ > contributors, all putting in their little piece. As your comments indicate, > we have not been able to consistently achieve the code quality that you > expect. There are many reasons for that. Probably it is due to inadequate > leadership, and for that I am responsible. However, some of these issues can > be mitigated by more feedback and more code review, and for that I am most > appreciative of your input. > > A few responses... > > On 6/09/2015 5:15 PM, Andrew Kelley wrote: >> >> PortAudio dumps a bunch of logging information to stdio without >> explicitly turning logging on. Here's a simple program and the >> corresponding output: >> https://github.com/andrewrk/node-groove/issues/13#issuecomment-70757123 > > > Those messages are printed by ALSA, not by PortAudio. We considered > suppressing them, but current opinion seems to be that if ALSA has problems > it's better to log them than to suppress them. That said, it's an open > issue: > > https://www.assembla.com/spaces/portaudio/tickets/163 > > Do you have any thoughts how how best to handle ALSA's dumping messages to > stdio? > >> Another example, when I start audacity, here's a bunch of stuff dumped >> to stdio. Note that this is the *success* case; audacity started up just >> fine. >> >> ALSA lib pcm.c:2338:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear >> ALSA lib pcm.c:2338:(snd_pcm_open_noupdate) Unknown PCM >> cards.pcm.center_lfe >> ALSA lib pcm.c:2338:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side >> ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel >> map >> ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel >> map > > > See above ticket. > >> Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1733 > > <snip> > > The "Expression ... failed" looks to me like a two level bug: #1 that it's > logging like that in a release build, and #2 that those messages are being > hit. (But as I say, PortAudio on Linux is not my area). I'll report these to > the PortAudio list. > > >> It would be helpful to me at least, to give a quick example of what a >> "meaningful error code" is and why PortAudio's error codes are not >> meaningful. >> >> >> PortAudio error codes are indeed meaningful; I did not intend to accuse >> PortAudio of this. I was trying to point out that error codes are the >> only way errors are communicated as opposed to logging. >> >> I changed it to "Errors are never dumped to stdio" to avoid the >> accidental implication that PortAudio has non meaningful error codes. > > > Given the error messages that you posted above, I can see your point. I am > not sure why the code is written to post those diagnostic errors in a > release build but I will check with our Linux contributor. > > >> In particular, as far as I know, there are no problems with >> PortAudio's >> handling of memory allocation errors. If you know of specific cases of >> problems with this I would be *very* interested to hear about them. >> >> >> Not memory, but this one is particularly striking: >> >> /* FEEDBACK: I'm not sure what to do when this call fails. >> There's nothing in the PA API to >> * do about failures in the callback system. */ >> assert( !err ); > > > > It's true, pa_mac_core.c could use some love. There is an issue on Mac if > the hardware switches sample rates while a stream is open. > > >> As for WMME and DirectSound, I think you need to be careful not to >> confuse "deprecated" with "bad." Personally I prefer WMME to anything >> newer when latency isn't an issue -- it just works. WASAPI has been >> notoriously variable/unreliably on different Windows versions. >> >> >> My understanding is, if you use DirectSound on a Windows Vista or >> higher, it's an API wrapper and is using WASAPI under the hood. > > > I believe that is true. Microsoft also know all of the version-specific > WASAPI quirks to make DirectSound work reliabily with all the buggy > iterations of WASAPI. > > >> May I suggest listing support for all of these APIs as a benefit of >> PortAudio? >> >> >> Fair enough. >> >> Would you like to have another look at the wiki page and see if it seems >> more neutral and factual? > > > I think it looks good. The only things I'd change: > >> *Supports channel layouts (also known as channel maps), important for >> surround sound applications. > > PortAudio has channel maps, but only for some host APIs as a per-API > extension. It's not part of the portable public API. You could say "Support > for channel layouts with every API" or something like that. > >> *Ability to open an output stream simultaneously for input and output. > > Just a typo, change to "Ability to open a stream simultaneously for input > and output." > > > Thanks, > > > Ross. > > > > > > > > > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp _______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
