ALSA/OSS linux audio driver priorities

Hey,

I recently found out that SDL prefers using OSS audio over ALSA audio
in Linux. This is a bit of a problem on systems using ALSA’s software
mixing (dmix), because ALSA’s OSS emulation doesn’t do any
software-mixing at all unless the OSS-using program is run through
aoss, which results either in no sound or blocking other apps
(including ALSA ones) from using sound while the OSS emulation is in
use. (Anyone know if there’s a reason ALSA can’t do a proper mixing OSS
driver btw? Why is the aoss hack required?). I’ve also noticed that
OSS emulation can have lower audio quality than pure ALSA.

So, I’m wondering if there’s any reason why SDL prefers OSS over ALSA
in Linux, and if not, if the priorities could be switched? (I know that
the SDL_AUDIODRIVER envvar can be used to override priorities, but it’d
be nice if things just worked in stead of having to resort to that).

  • Gerry

Gerry JJ a ?crit :

Hey,

I recently found out that SDL prefers using OSS audio over ALSA audio
in Linux. This is a bit of a problem on systems using ALSA’s software
mixing (dmix), because ALSA’s OSS emulation doesn’t do any
software-mixing at all unless the OSS-using program is run through
aoss, which results either in no sound or blocking other apps
(including ALSA ones) from using sound while the OSS emulation is in
use. (Anyone know if there’s a reason ALSA can’t do a proper mixing OSS
driver btw? Why is the aoss hack required?). I’ve also noticed that
OSS emulation can have lower audio quality than pure ALSA.

So, I’m wondering if there’s any reason why SDL prefers OSS over ALSA
in Linux, and if not, if the priorities could be switched? (I know that
the SDL_AUDIODRIVER envvar can be used to override priorities, but it’d
be nice if things just worked in stead of having to resort to that).

  • Gerry

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is wrong.
You can downloads the last version : SDL-1.2.12.tar.gz.
Uncompress it :
$tar -zxvf SDL-1.2.12.tar.gz
Go to the new folder :
$cd SDL-1.2.12
and try :
$./configure --help
You can see the line :
–enable-alsa support the ALSA audio API [default=yes]
So no problem with SDL and ALSA.
Maybe you have a bad package and you must build yourself.
Good luck.

Den Tue, 07 Aug 2007 17:14:46 +0200
skrev YuGiOhJCJ :
[…]

You can see the line :
–enable-alsa support the ALSA audio API [default=yes]
So no problem with SDL and ALSA.

No, you misunderstand. I’m talking about run-time driver priorities,
not what drivers are enabled in SDL. SDL currently tries to use OSS
before it tries ALSA. Ie, on a system with ALSA and OSS emulation
enabled (and no other sound drivers), setting SDL_AUDIODRIVER=dsp has
no effect, since it’s the same as SDL’s default behaviour in that case.

  • Gerry

Hello !

$./configure --help
You can see the line :
–enable-alsa support the ALSA audio API [default=yes]
So no problem with SDL and ALSA.
Maybe you have a bad package and you must build yourself.

But this does not change the sequence of testing
from SDL. It means build with support for ALSA.

CU

I believe the attached patch should make ALSA preferred over OSS.On Tue, 2007-08-07 at 17:22 +0200, Gerry JJ wrote:

Den Tue, 07 Aug 2007 17:14:46 +0200
skrev YuGiOhJCJ :
[…]

You can see the line :
–enable-alsa support the ALSA audio API [default=yes]
So no problem with SDL and ALSA.

No, you misunderstand. I’m talking about run-time driver priorities,
not what drivers are enabled in SDL. SDL currently tries to use OSS
before it tries ALSA. Ie, on a system with ALSA and OSS emulation
enabled (and no other sound drivers), setting SDL_AUDIODRIVER=dsp has
no effect, since it’s the same as SDL’s default behaviour in that case.


Alan.

“One must never be purposelessnessnesslessness.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl-alsa-default.patch
Type: text/x-patch
Size: 551 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070807/5810016d/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070807/5810016d/attachment.pgp

I believe the attached patch should make ALSA preferred over OSS.

The reason it wasn’t preferred in the past is that there were bugs
with ALSA hanging on open when (real) OSS was being used, but some
OSS drivers would allow multiple opens.

There were also audio quality and latency problems with ALSA that
weren’t present in the OSS emulation.

I don’t know if these are still the case…

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

I believe this is because when you are using a modern ALSA natively it
and you do dmixing the samples are copied into the shared memory of the
first process using ALSA which then combines the samples and sends the
(single) output to the kernel. If you are using ALSA’s kernel OSS
emulation then by the time the OSS emulation has the sound samples it is
effectively too late as you are already in the kernel and no longer have
access to ALSA’s virtual devices/dmixing which are implemented as
libraries. Also, traditionally /dev/dsp has only been openable by one
process (there were some OSS drivers that broke this rule though). This
is speculation - try the ALSA lists of a real answer.

Some new distributions default to only shiping the SDL ALSA plugin out
of the box. For me, going straight to ALSA when running SDL programs
usually results in better results than using OSS -> aoss -> ALSA but
there are others who have very real problems with SDL ALSA output and
default SDL to a different sound method.On Tue, 2007-08-07 at 17:06 +0200, Gerry JJ wrote:

I recently found out that SDL prefers using OSS audio over ALSA audio
in Linux. This is a bit of a problem on systems using ALSA’s software
mixing (dmix), because ALSA’s OSS emulation doesn’t do any
software-mixing at all unless the OSS-using program is run through
aoss, which results either in no sound or blocking other apps
(including ALSA ones) from using sound while the OSS emulation is in
use. (Anyone know if there’s a reason ALSA can’t do a proper mixing OSS
driver btw? Why is the aoss hack required?). I’ve also noticed that
OSS emulation can have lower audio quality than pure ALSA.


Sitsofe | http://sucs.org/~sits/

Hello !

I believe the attached patch should make ALSA preferred over OSS.

The reason it wasn’t preferred in the past is that there were bugs
with ALSA hanging on open when (real) OSS was being used, but some
OSS drivers would allow multiple opens.

There were also audio quality and latency problems with ALSA that
weren’t present in the OSS emulation.

This is still true for my with experience.
Not for good cards with emu10k1 chipset for
example, but with cheap noname ones.

CU

I don’t know if these are still the case…

I think those have probably been fixed by now. Also, the kernel
developers have been pretty clear that ALSA is the way forward, and OSS
will eventually be removed from the kernel wholesale.

That being said, in an ideal world everyone else would stop providing
OSS wrapper layers, so SDL would only pick OSS if it’s really there, and
gracefully pick the real target instead of the real target’s emulation
layer otherwise.

In reality, I guess we’ll just have to move ALSA above OSS in our
priority list.

–ryan.

In reality, I guess we’ll just have to move ALSA above OSS in our
priority list.

Okay. Ryan, can you do this for both 1.2 and 1.3?

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Something (an issue with either a driver/dmix/sdl or combination of the
previous pieces) is still here. See
https://bugs.launchpad.net/ubuntu/+bug/66483 .On Tue, 2007-08-07 at 17:09 -0400, Ryan C. Gordon wrote:

I don’t know if these are still the case…

I think those have probably been fixed by now. Also, the kernel
developers have been pretty clear that ALSA is the way forward, and OSS
will eventually be removed from the kernel wholesale.


Sitsofe | http://sucs.org/~sits/

Den Wed, 08 Aug 2007 07:18:27 +0100
skrev Sitsofe Wheeler :

Something (an issue with either a driver/dmix/sdl or combination of
the previous pieces) is still here. See
https://bugs.launchpad.net/ubuntu/+bug/66483 .

That’s interesting. They describe lower sound quality and crackling
problems with ALSA (buffer overruns? seems to be more than just that
though), which is exactly the kind of thing I’ve seen with ALSA’s OSS
emulation (but not pure ALSA). I’ve also reproduced this without using
SDL_mixer, playing a simple square wave with pure SDL audio. The thing
is, they (in that link) seem to have tracked the issue down to dmix
(also seehttps://bugtrack.alsa-project.org/alsa-bug/view.php?id=3253)
but the OSS emulation doesn’t use dmix unless the program using OSS is
run through aoss, which I didn’t do when I tested this. I think it’s
definitely the same issue though, since the symptoms are the same and
the system does use the intel8x0 driver.

So anyways, if it’s a low-level driver issue, favouring OSS over ALSA
in SDL wouldn’t really fix things with ALSA’s OSS emu since the problem
goes deeper than that. It does seem to be more common with ALSA though.
On the other hand again, there’s still the blocking-sound-in-other-apps
issue. Sigh.

  • Gerry

Something (an issue with either a driver/dmix/sdl or combination of the
previous pieces) is still here. See
https://bugs.launchpad.net/ubuntu/+bug/66483 .

It seems strange that it’s only when you change the volume in the
game…that sounds like it would have to be an SDL_mixer bug, but I’m
wondering if that part is bogus.

I’ve posted a request for more information on that report.

–ryan.

Hello,

This is my first post on the list, so I’d like first to thank Sam
Latinga (and everyone else) for this great library!

Ryan C. Gordon wrote:

It seems strange that it’s only when you change the volume in the
game…that sounds like it would have to be an SDL_mixer bug, but I’m
wondering if that part is bogus.

Since a few months I’m a contributor to the game Neverball, and this
"audio crackling bug" is something we have encountered too.

The interesting point is that some of our players have a similar problem
on windows: audio crackling that disappear when setting the volume to
100%. If this is the same bug, this would suggest that it’s not directly
related to alsa.

Here’s a link to a thread in the Neverball forum discussing the audio
crackling:

http://www.nevercorner.net/forum/viewtopic.php?pid=10806#p10806

This was a few months ago, but I can bring back the subject on the forum
if you want more precisions. What kind of information would be useful?

regards,

– Lorant

Hello,

this is seen a lot by people who use pygame too. On windows, and linux.

Sometimes the fix is to increase the buffer size before initialising
sdl_mixer. This works for 99% of people, but then of course the
latency of the sounds goes up.

After a lot of 1024 * 3 seems to be the minimum size which stops the
crackling for most people.

Maybe the sound thread could use a higher priority?

Or maybe there’s something else that can be done to feed the data
through more efficiently.

I don’t have a computer which has this behaviour, so I’ve never really
been able to dig into it.

It’s a fairly common problem, mainly on windows machines with on board
integrated sound cards. I don’t recall hearing about win98 problems,
I think only xp/2000. As the code was probably written with win95/98
in mind, that could explain the problem. Other sound programs on the
machine do not have the crackling.On 8/10/07, Laurent Moussault <moussault.laurent at free.fr> wrote:

Hello,

This is my first post on the list, so I’d like first to thank Sam
Latinga (and everyone else) for this great library!

Ryan C. Gordon wrote:

It seems strange that it’s only when you change the volume in the
game…that sounds like it would have to be an SDL_mixer bug, but I’m
wondering if that part is bogus.

Since a few months I’m a contributor to the game Neverball, and this
"audio crackling bug" is something we have encountered too.

The interesting point is that some of our players have a similar problem
on windows: audio crackling that disappear when setting the volume to
100%. If this is the same bug, this would suggest that it’s not directly
related to alsa.

Here’s a link to a thread in the Neverball forum discussing the audio
crackling:

http://www.nevercorner.net/forum/viewtopic.php?pid=10806#p10806

This was a few months ago, but I can bring back the subject on the forum
if you want more precisions. What kind of information would be useful?

regards,

– Lorant


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org