[Portaudio] stable candidate 20110317
rossb-lists at audiomulch.com
Fri Mar 18 00:30:52 EDT 2011
Michal Suchanek wrote:
> As I see it PortAudio is not suitable for my environment of a
> prepackaged distribution.
But if I understand correctly, you don't seem to be using a prepackaged
distribution. You are using a modified distribution: one where you've
uninstalled ALSA, the default Linux audio API, but not rebuilt userspace
applications that depend on ALSA (i.e. PortAudio applications that will
by-design use ALSA as the default host API if they are built with ALSA
> A prepackaged distribution allows you to try
> several solutions quickly and also quickly trash those that did not
> work. It also maintains the packages built with the same options for
> multiple architectures requiring little effort to instantiate the same
> setup across multiple systems.
But you have changed the configuration -- you have removed ALSA. I'm not
sure if it is reasonable to expect precompiled packages that depend on ALSA
(eg PortAudio) to work correctly in this scenario.
> PortAudio does not work for me and as alternative solutions exist and
> the PortAudio community appears hostile towards making it work I am
> not willing to take the burden of maintaining the package for multiple
> architectures on myself and so I trash it.
We have tried to answer your questions and explain the situation as it
stands. I am still trying to understand exactly what your requirements are
and whether they warrant raising a bug report. I don't really understand how
you can interpret this as hostile. As it stands, you started off telling us
that PA is broken because it doesn't support having a configuration file,
and now it transpires that PA is broken because it doesn't support removing
ALSA from the system after compiling-in ALSA support.
Although we are always interested to hear how other libraries work, there
are a number of ways in which PortAudio differs from the other libraries you
have mentioned, so the argument that "PortAudio is broken because it doesn't
work exactly the same way as other APIs" is not a strong one.
PA has a streamlined default device process in that we use the default
device of the _underlying_ API. In this case, the ALSA default device. That
way we don't need a configuration file, and we work the same way as all
other applications that use the ALSA default device, without the need for
>From what you have told us, you have removed ALSA support from your kernel.
I am still unsure how this works at all unless you have kept the ALSA
userspace library installed.
But in my opinion, there are at least two potential bugs here:
1. """When PA is configured to use ALSA at build time, if ALSA is not
installed on the client machine PA sees no devices, and hence no default
2. """When the PA default host API (eg ALSA) has no devices, PA doesn't try
to use the next API (eg OSS) in the list)."""
Personally I don't know if either of these are real bugs yet.
(1) describes a scenario that was never considered during design -- we do
face a similar situation on Windows with WASAPI however so it may be
worthwhile us considering adding a test for host API presence. Although in
your case it is unclear to me how this would work if you still have ALSA
user space installed.
(2) has been discussed here before. The issue here is related to having
disconnectable devices. If ALSA is installed, but your audio device is a
disconnected USB device (so no devices), does it really make sense to switch
which host API is used to OSS?
More information about the Portaudio