RFC: Disable the ALSA driver by default.

[Luke Yelavich]

On Sat, Aug 30, 2014 at 01:23:41AM AEST, Trevor Saunders wrote:
> On Fri, Aug 29, 2014 at 04:14:00PM +1000, Luke Yelavich wrote:
> > Hey folks.
> > One thing I have seen mentioned in many a discussion about 
> > speech-dispatcher in the recent past is about the state of the ALSA output 
> > driver, and its tendency to crash. I am wondering whether it is worth 
> > considering disabling the ALSA driver by default for now, and only building 
> > it if the user explicitly enables it at build time. For now, we have the 
> > libao driver as an alternative, and libao can be configured to use ALSA 
> > directly. Longer term, it would be better to have a direct ALSA driver, but 
> > until someone can take the time to fix its bugs, I'd rather users have a 
> > stable ALSA experience for now.
> > 
> > I haven't tested the ALSA driver myself recently, but I used to have 
> > regular crashers when I did use it, and that was on a single CPU/single 
> > core system. Given that the ALSA driver issues are likely threading 
> > related, I dare say it is much worse on multi-CPU/multi-core systems.
> 
> istr it was actually some sort of buffer under / over run.  Anyway I
> don't think its gotten much worse over the years as I've gone from
> single / double core machines to 4 or 8 core ones.
> 
> > This is something I am considering for the 0.8.1 release. Any thoughts, or 
> > alternative suggestions are welcome.
> 
> I think the goal of getting people to not use the alsa driver when they
> have alternatives makes sense.  However I wonder if it wouldn't make
> more sense to just change our defaults to prefer libao to alsa.  I think
> we could probably just switch the order of the alsa and libao checks in
> configure.ac to accomplish that.  I do wonder though why it is that we
> don't add all the audio backends we find to default_audio_method given
> it supports more than one at least in theory.

This makes sense, so for 0.8.1 I'll switch the order for now, and we can adjust 
things further in the future.

Luke