Re: [Portaudio] Re: portaudio in Debian, license updates?
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.
Reply to: