[Portaudio] selecting the sound IO of portaudio?

[Richard Ash]

On Mon, 2011-03-21 at 03:28 +1100, Ross Bencina wrote:
> Thanks Richard. I think that supports my previous comments and clears things 
> up considerably. It sounds like PA is doing the right thing to use ALSA 
> "default" device, and assuming that ALSA is installed, this will provide the 
> expected behavior, and conformance to whatever default ALSA configuration 
> the user selects in ~/.asounrc
> 
> Of course it doesn't solve Michal's problem of falling back to OSS if ALSA 
> kernel driver is not installed. Do you have an opinion on that? Is it going 
> to be easy to detect if ALSA is not in the kernel but has user space libs 
> installed? (I hope I'm correctly characterising Michal's configuration 
> here).

I think it's going to be quite easy - we just detect if there are _any_ 
ALSA devices on the system at all (which I think can be done with the
ALSA API functions). If there are, then ALSA is working, if not then we
decide that ALSA doesn't work and move on.

> For the sake of completeness, there is one option that we havn't discussed 
> in this thread (and that PA has partially supported in the past):
> 
> Allow default PA devices to be overridden by environment variables. Since 
> environment variables can be set per-process this isn't exactly a global 
> setting.
> 
> Of course this has many of the same negatives as configuration files: it 
> short-circuits platform-level default settings. On the other hand it would 
> make running the individual tests accross different host APIs much easier.

I would accept this as a means of an application setting which PA device
to use (over-riding the default) without question, but that would be an
application setting.

Should PortAudio implement something? It wouldn't do any harm (unlike
some alternatives), on the assumption that with no variable set, it
behaves like it does at the moment. At that point we are essentially
making the environment variable mechanism optional at point of use. My
feeling is that this comes into the category of things that I wouldn't
object to if someone provided a patch (one that worked for all host
APIs), but wouldn't see as a priority for developer time to fix.

Presumably it would have to define a separator character, so that the
string in the variable would consist of a HostAPI<separator>DeviceID
type value.

> > I think this is a valid problem, and one Audacity has hit in the past
> > (when the Linux default device was OSS, which often doesn't work). I
> > think there does need to be either a means of asking "which device from
> > any API should I use as default?" which can cope with run-time
> > availability of different APIs. The situation will get significantly
> > worse if we end up supporting PulseAudio (which is layered on top of
> > ALSA in most cases) natively.
> 
> If you are prepared to accept that it's always a hierachical decision: 
> "which is the default host API? what's it's default device?" then the 
> question can be simplified to "which host API is the default API from which 
> the default device will be selected". This assumes that input and output 
> device (if separate) must belong to the same host API. I think that's a 
> valid assumption since it is not possible to open full duplex streams with 
> different host APIs for input and output. This is the way things work at the 
> moment.
> 
> Right now each host API defines PA default devices. The first host API in 
> the initializer list is used to source the default devices (this is the 
> "default host API"). Current examples: On Linux this is ALSA unless ALSA is 
> not compiled in. On Windows this is WMME (although arguably this should be 
> WASAPI on Windows Vista and 7). On Mac OS this is always CoreAudio.
> 
> Enumerating the options, we have:
> 
> 1. Default host API is fixed at build-time (current situation).
> 
> 2. Default host API is determined dynamically/automatically at run-time
> 
> 3. Default host API is determined via a configuration file.
> 
> Given previous discussions, (2) is the preferred choice. I guess the main 
> question with the dynamic/automatic default host API approach is: can we 
> always implement a reasonable huristic to select the default host API. Will 
> this heuristic be appropriate for all system configurations or would there 
> be cases where the user would reasonably need to manually specify the 
> default host API?
I can't currently think of one. In general, although there are multiple
APIs floating around, nearly all of them are there for legacy
compatibility or because they are being used under the bonnet, with
everything intended to go through the "correct" API. So option 2 is a
definite improvement, and we can't currently work out why it isn't a
sufficient solution.

> In Michal's case it would be possible to implement option (2) (just detect 
> if ALSA is installed and if not, fall back to the next host API in the 
> list). Same goes for switching to WASAPI on Vista/7. I'm not sure about the 
> PulseAudio case -- would it be appropriate to always use PulseAudio as the 
> default if it was installed/running?

I'm sure the PulseAudio people would say yes, and I'm prepared to agree.
If a system has PulseAudio, then not using it will inevitable cause
problems for users. If the user wants to disable PulseAudio and use
ALSA, they can either
1) Do so at the system level (if they use the sound device, they should
have root access as well to attack daemons). At that point, PortAudio
should realise there are no PulseAudio devices and switch the default to
ALSA.
2) Select a specific sound device in their application to use ALSA of
whatever.

> Seems to me we can probably take this approach.
Yes

Richard