[Portaudio] stable candidate 20110317

[Ross Bencina]

Michael,

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 
support).


> 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 
additional configuration.

>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 
device."""

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?

Thank you

Ross.