Standardize on audio output (esd, oss)

[Matt Zimmerman]

Our agreed standard was to use the OSS API with ALSA drivers. However, we seem
to have some applications which access the sound device directly at /dev/dsp,
and others which use esd. If esd is running, /dev/dsp is inaccessible with many
sound devices (only a single open is supported).

Should we standardize on esd? Perhaps it is not suitable for video with
synchronized audio, and other advanced applications, but we need some answer to
this.

[Scott James Remnant (Canonical) (canonical-scott)]

This is actually probably a bug with esd ... why is it locking /dev/dsp all the
time it's running?

Isn't there some ALSA developer FAQ about this, something to do with using
O_NONBLOCK ?

[Jeff Waugh (jdub)]

Remember we're using the libesd for oss, not alsa.

Plus, on crappy ("the majority of") audio hardware, you can't open /dev/dsp more
than once, which I *think* is what's happening here, rather than explicit
locking or anything.

I think we basically have to suck up esd by default at the moment. Perhaps we
can work on some ALSA dmix autoconfiguration for Hoary, but it's Hard.

[Matt Zimmerman (mdz)]

My understanding was that esd was supposed to release the device after a few
seconds of inactivity. The config file says 5 seconds:

mdz@max ~ $ cat /etc/esound/esd.conf
[esd]
auto_spawn=0
spawn_options=-terminate -nobeeps -as 5
spawn_wait_ms=100

So this should only happen when another application is using esd, or if has
within the last 5 seconds

[Thom May (thombot)]

(In reply to comment #2)
> Remember we're using the libesd for oss, not alsa.
>
> Plus, on crappy ("the majority of") audio hardware, you can't open /dev/dsp more
> than once, which I *think* is what's happening here, rather than explicit
> locking or anything.
>
> I think we basically have to suck up esd by default at the moment. Perhaps we
> can work on some ALSA dmix autoconfiguration for Hoary, but it's Hard.

Agree with the use of ESD at this point by default. This requires a change for
gstreamer at least. Gaim is set to choose automatically, and appears to use ESD
for me.

[Jeff Waugh (jdub)]

Other ones to do:

* totem (it's own xine config) -> I'll take this one.
* gnomemeeting... uses alsa only. ber.

[Jason Toffaletti (jason)]

Can we go back to discussing why dmix isn't an option? Just saying it is hard
doesn't seem valid to me. I have helped at least 10 people in #ubuntu during the
past couple days switch gstreamer to use ALSA and setup an asoundrc to do
multichannel mixing with dmix. No one has reported any problems and they've all
been very grateful to have gaim + totem/rhythmbox able to play sound at the same
time.

I'm not clear on why dmix is hard or why ALSA is too buggy. dmix mixes unlimited
channels extremely efficiently in software. I've had 10 apps simultaneously
playing 16bit, 44100, stereo audio with no visible performance hit. ALSA+dmix is
definitely the solution for the future, and I think solving any problems now
will put Ubuntu way ahead.

[Jason Toffaletti (jason)]

Ok correction, tonight I helped 4 more people and one had problems with
gstreamer-alsa crashing rhythmbox. However, he was willing to live without
gstreamer apps (rhythmbox). Before I helped him he was using esd and rhythmbox
was working with gstreamer-esd, but mozilla-flash and tuxracer sound wasn't
working at all and neither was mixing. He was much happier using ALSA, even with
the crashing. If that gstreamer-alsa crash is something we can fix, I think it
would be a better fix than anything having to do with esd.

[Ben Roe (ben-ubuntu-benroe)]

IMO, the best solution is just to use software mixing with alsa and run esd for
those apps that need it - GNOME desktop sounds only seem to work with esd, for
example. Use direct ALSA for everything that can use it, with esd for anything
that doesn't.
That's how I've run with previous distributions and it works very well.

[Nathaniel McCallum (nmccallum)]

Bug #8403 suggests that upgrading to a newer version of esound may fix this.
Indeed we are about six releases behind.

[Jeff Waugh (jdub)]

Jason: We're too late in the release process to make a change like that. Getting
DMIX to work nicely by default in as many circumstances as possible will involve
a lot of work and testing -> this might be a nice option for HoaryHedgehog,
although we're also going to be looking at polypaudio.

Nathaniel: Approved sync for esound on the other bug#, assigned to Seb.

[Jason Toffaletti (jason)]

(In reply to comment #10)
> Jason: We're too late in the release process to make a change like that. Getting
> DMIX to work nicely by default in as many circumstances as possible will involve
> a lot of work and testing -> this might be a nice option for HoaryHedgehog,
> although we're also going to be looking at polypaudio.

OK, I completely agree, you need to get warty out the door, and I guess if you
made the choice to use esd months ago it is too late to switch. I've got many
ideas then for hoary. I'll move the discussion to the devel mailing list though.

[Matt Zimmerman (mdz)]

I still got segfaults left and right with the new libesd-alsa0

[Matt Zimmerman (mdz)]

*** Bug 8418 has been marked as a duplicate of this bug. ***

[Thom May (thombot)]

Ok, we're sticking with ESD for warty, resolving this bug to LATER so we can
revisit it in Hoary timescale.
(Need to resolve so I can close 1349 :P )

[Richard Laager (rlaager)]

What ever became of this? Is ALSA dmix being used in Dapper (or previous)?

[Matt Zimmerman (mdz)]

In Breezy, yes

[Jason Toffaletti (jason)]

My understanding is that setting up dmix with ALSA on a wide variety of hardware is difficult because there are potentially a lot of variations. Compiling this information is difficult to do and it needs to be done before dmix can be made the default.

[Daniel T Chen (crimsun)]

ALSA is dmixed by default as of 1.0.9rc2 for the vast majority of consumer sound chipsets (thus Matt's answer "In Breezy"; notable exceptions are ice1712 and ca0106, the latter of which had dmix enabled in 1.0.10rc1). Since this was an upstream decision, Ubuntu (and other distros) has been able to reap the benefits.