[Portaudio] Re: portaudio in Debian, license updates?

[Ross Bencina]

Hi Markus

First of all, thanks for taking the time to put your concerns in writing --  
some of these issues are news to me. I've received a lot of traffic over 
this issuein the last 24 hours and I'll have get back to you with some more 
detailed responses to the strategic issues, however I want to respond 
immediately to some factual issues which your email raised.

> The desire by the Audacity development team to
> look at other APIs is because of the following factors. Note that I can
> only speak for myself here, though I think that other members of the
> team may share some of the thoughts outlined below:
>
> * While I agree that there may be constant development on PortAudio v19
> CVS, I cannot see that there is a definitive plan to release a new
> stable version or even incremental releases to v18.

It is true that there is no published plan. The current status is that we 
are in the process of migrating to SVN afterwhich we will be restructuring 
the V19 directory heirarchy and then we will be in a position to release 
V19. I believe that most/all active development is on the v19-devel branch.

> It is very
> frustrating having to use a library in a stable product that has been in
> beta state literally for years. I'm not saying, you should release a
> stable v19 tomorrow.

This is a reasonable concern. I think that the "beta" perception may be 
limited to people who aren't directly engaged in PortAudio development.

> But at least making incremental releases with a
> clear management of bug reports and clear priority assignment on those
> reports would help the process. This would also assist in release
> planning for applications depending on Portaudio.

Currently we depend on people posting bugs to the PortAudio mailing list. I 
am not aware of any bugs which have been raised which were not fixed more or 
less immediately. I'm not saying there aren't bugs, or there aren't bug 
reports which I don't know about. But I havn't seen any indication that we 
are inundated with bug reports and hence need tracking/prioritisation. If 
you have posted bugs which havn't been addressed (or know of some) please do 
let me know and we can assess and respond to the situation in more detail.


> * Portaudio v18 is way to outdated. For example, it does not support
> ALSA on Linux, and it does not have the same latency management
> Portaudio v19 has. Therefore we must move away from it. I assume the
> "commercial applications" you're talking about use Portaudio v18.

I have three applications in mind. JSyn from SoftSynth, Plogue Bidule (and 
OEM derivatives) and AudioMulch. The latter two use V19. I'm sure other 
people on the PortAudio list can let you know about others, there are 
certainly many listed on the PortAudio web site.


> * Portaudio v19, on the other hand, is simply not usable on some
> platforms. E.g., I am a maintainer of the German Audacity forum
> (http://audacity.fuchsi.de/) and I regularly receive reports that
> Portaudio v19 does not work correctly. Speaking for myself here, I have
> two machines here with ALSA (Ubuntu 5.10), and all ALSA apps I've tested
> so far work, except Audacity, when compiled with Portaudio v19.
> Sometimes playing works, but after some seconds, the application just
> hangs. Another field of problems is on the Mac. It seems that there are
> lots of Mac users who are having problems with Portaudio (v18 and v19).
> We're not talking about multichannel soundcards here, but about USB
> mics, simple USB sound adapters etc., stuff that really should work. I
> understand that you didn't write the Mac port for Portaudio, but still
> switching to RtAudio might be of help here :)

Do you have experience with the new AUHAL PortAudio version which has been 
under heavy development in the last 2 months? Once again I am concerned that 
you are complaining about problems which were never reported to our 
developers through our mailing list. I strongly invite you to participate in 
our community (as you are now, thank you!) but submitting problem reports to 
us -- this is how things get fixed.


> * There are a number of patches which were submitted to PortAudio by us,
> which have not been incorporated into PortAudio. This is one of the
> reasons why we maintain a locally patched version of PortAudio. It would
> be good to have a formal patch management, like the one that is
> available on Sourceforge, so we would know which patches are accepeted
> and which ones are rejected and for which reason.

I would appreciate it if you could send me another email detailing these 
patches and who they were sent to. If this is really a problem then 
obviously we need to look into ways of addressing the problem. My focus for 
a number of years has been on V19, however I am not aware of any uncommited 
patches. I'm sure we would be happy to give you write access to our 
repository if your patches are suitable.


> As I see it, the goals of the projects Portaudio and Audacity just seem
> to differ. While development of Portaudio seems to incorporate a "it
> will be ready when it is done" approach (which I think is perfectly okay
> for an open source project!), Audacity needs something that works _now_,
> and on all platforms. This is why we're looking at alternatives.

That's fair enough. I think you also need to be aware that participating in 
a community is part of what makes Open Source work. The Open Source audio 
community is already very small.. fragmenting it further due to impatience 
(as has happend with RtAudio) is not a strategy which I see as being either 
good for productivity (it spreads the communities already limited resources 
even more thinly) nor is it good for the community itself. But perhaps I can 
make a more concrete argument:

Audio i/o libraries are not prestigious or glamourous, but we all need them. 
I don't believe that anyone (even me) wants to spend all their time working 
on an audio i/o library. To make such a library work and continue to work 
over a long period of time requires input from users of the library (such as 
the input you are currently offering, which I wholeheartedly welcome). It 
doesn't make sense to think of such a library as a component which you can 
just "choose to use and leave it to the maintainers".. the maintainers are 
part of the community too.. we aren't "audio api specialists" in the same 
sense as the kernel group are "os kernel specialists" we're just a bunch of 
audio developers who are trying to share the load around by cooperating on 
some infrastructure which we all need. If our process needs improvement, as 
you suggest, then we should make that happen.. I'd prefer that the energy 
was put there than in you porting Audacity to RtAudio...

Best wishes

Ross.