On 6 October 2011 17:26, Alexandre Ratchov <a...@caoua.org> wrote: > On Thu, Oct 06, 2011 at 08:58:16PM +0200, Ingo Schwarze wrote: >> Hi Alexandre, >> >> Alexandre Ratchov wrote on Thu, Oct 06, 2011 at 08:29:26PM +0200: >> >> > On the one hand, we expect audio to work by default. On the other hand >> > format conversions, channel mapping, resampling and alike belong to >> > the audio sub-system; until 2009, this used to be the audio(4) driver >> > itself. But later, instead of extending the audio(4) driver, we put >> > new audio code in aucat(1), which amongs others, has the advantage of >> > running as unprivileged user rather than in supervisor mode. From this >> > standpoint, there should be an instance of aucat(1) running by default >> > for each instance of audio(4), ie for each sound card; [...] >> >> Really? >> >> Here is the list of daemons currently enabled by default: >> >> syslogd pflogd sshd sendmail inetd cron >> >> These are useful on almost any system, no matter whether >> server or desktop. >> >> Unless i misunderstand, aucat will often be useful on the desktop. >> But do you also run it on your servers in the datacenter? > > well, consider aucat a an extension of the audio(4) driver. Except > that parts of the code are were moved in userspace. > > On servers you could disable audio, set aucat_flags=NO and recompile > GENERIC with audio support disabled. > >> Or do you argue that disabling it on servers is less work >> than enabling it on workstations? > > Not really, my point is that currently audio works by default on > OpenBSD, on servers, laptops, PDAa. More and more code of the audio > sub-system that would be in the kernel is being pulled in userland, so > if we accept that audio should work by default, aucat should be > enabled by default. > >> Or do you argue that it doesn't matter running it even where >> it is not needed? >> > > Somewhat yes, if there are no audio devices or no audio program is > run, aucat does nothing and shouldn't hurt. > > -- Alexandre > >
We could enable aucat if the user chose "yes" on "Do you expect to run X ?" on the install script. I think it's fair to assume that if the user is running X, he probably wants audio.