On Sat, Sep 5, 2015 at 11:04 PM Ross Bencina <rossb-li...@audiomulch.com> wrote:
> > * Ability to connect to multiple backends at once. For example you > > could have an ALSA device open and a JACK device open at the same > > time. > > PortAudio can do this just fine. Very old versions of PortAudio only > allowed one host API to be active at a time. But for at least 5 years > "V19" has supported simultaneous access to multiple host APIs. > Thank you for the correction and I apologize for my oversight. Fixed. > > * Exposes extra API that is only available on some backends. For > > example you can provide application name and stream names which is > > used by JACK and PulseAudio. > > PortAudio does have per-host-API extensions. For example it exposes > channel maps (another feature listed) for host APIs that support them. > Another example: on Mac OS X it provides an extension to control > exclusive-mode access to the device. > !! My goodness. I did not see PortAudio's platform-specific extensions until now. They are a bit hidden in the documentation. I corrected this in the wiki page as well. > > * Errors are communicated via meaningful return codes, not logging to > stdio. > > PortAudio has a rich set of error codes, mechanisms for converting them > to text strings, and also provides access to underlying native error > codes and error text. > > I am not clear what your claim of "not logging to stdio" is about. The > only thing PortAudio prints to stdio is diagnostic debugging > information. And only when debug logging is turned on. Usually it's used > to diagnose bugs in a particular PortAudio host-api back end. > 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 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 Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1733 Expression 'AlsaOpen( &alsaApi->baseHostApiRep, params, streamDir, &self->pcm )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1900 Expression 'PaAlsaStreamComponent_Initialize( &self->capture, alsaApi, inParams, StreamDirection_In, NULL != callback )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 2167 Expression 'PaAlsaStream_Initialize( stream, alsaHostApi, inputParameters, outputParameters, sampleRate, framesPerBuffer, callback, streamFlags, userData )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 2836 Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4607 ALSA lib pcm_dsnoop.c:614:(snd_pcm_dsnoop_open) unable to open slave (repeated many times) ALSA lib pcm_dsnoop.c:614:(snd_pcm_dsnoop_open) unable to open slave Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1733 Expression 'AlsaOpen( &alsaApi->baseHostApiRep, params, streamDir, &self->pcm )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1900 Expression 'PaAlsaStreamComponent_Initialize( &self->capture, alsaApi, inParams, StreamDirection_In, NULL != callback )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 2167 Expression 'PaAlsaStream_Initialize( stream, alsaHostApi, inputParameters, outputParameters, sampleRate, framesPerBuffer, callback, streamFlags, userData )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 2836 Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4607 Expression '*idev = open( idevName, flags )' failed in 'src/hostapi/oss/pa_unix_oss.c', line: 832 Expression 'OpenDevices( idevName, odevName, &idev, &odev )' failed in 'src/hostapi/oss/pa_unix_oss.c', line: 878 Expression 'PaOssStream_Initialize( stream, inputParameters, outputParameters, streamCallback, userData, streamFlags, ossHostApi )' failed in 'src/hostapi/oss/pa_unix_oss.c', line: 1249 > 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. > > * Meticulously checks all return codes and memory allocations and uses > > meaningful error codes. Meanwhile, PortAudio is a mess. > > PortAudio is meticulous enough to mark where further code review is > needed. For example, many of the FIXMEs that you indicate in the link > were added by me during code review: > https://gist.github.com/andrewrk/7b7207f9c8efefbdbcbd > > But note that not all of these FIXMEs relate to the listed criticisms. > > 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 ); Each of these items pointed out in the gist above are problems with PortAudio. Each item represents one or more of these: * a misleading or false comment * a bug * an unhandled error condition * an indication that the PortAudio API is not an adequate abstraction * a demonstration that the developer did not carefully read the documentation of the host API > * Ability to monitor devices and get an event when available devices > > change. > > For anyone reading, there is PortAudio code for doing this under Windows > on the hot-plug development branch. If someone would like to work on > finishing it for other platforms that would be great. > libsoundio has this working on every backend without resorting to polling on a timer, including ALSA, and I welcome you to look at the source code for inspiration if it helps :-) I certainly looked at PortAudio for inspiration at times. > > * Does not have code for deprecated backends such as OSS, DirectSound, > > asihpi, wdmks, wmme. > > Not all of these are deprecated. I'm pretty sure OSS is still the > preferred API on some BSD systems. ASIHPI is not deprecated, > AudioScience HPI drivers are newer than their ALSA drivers > (http://www.audioscience.com/internet/download/linux_drivers.htm). > WDM/KS is still the user-space direct access path to WDM drivers. > Thank you for the correction. > 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. > 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?
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
