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
