SDL_mixer redux

SDL Development
1

Hi,

After much searching on the internet (more than 10 hours sitting in front of
google results) I continue to be stumped by the problem of efficient audio
rate conversion.

What is needed: to play audio that comes at a sample rate of 44100Hz on
hardware that seems locked at 48000Hz, as fast as possible.

The rough measurements I made are as follows:

My linux system uses alsa.

Any application I use, including my own, to play 44100 audio will sound
fine, but use 4-9% CPU power at all times. Some dedicated audio player
applications use even more.

Mplayer, playing the same audio, reports that the audio is at 44100Hz, but
that alsa is operating at 48000Hz, and uses <0-3% CPU power at all times.
When running with this performance, Mplayer seems to be using alsa and
mp3lib.

If I make my application play the audio at 48000Hz (argument audio_rate
passed to Mix_OpenAudio), then it runs not quite as fast as Mplayer, but
definitely faster than when playing at 44100Hz, as much as 5% less CPU power
in use.

If I tell Mplayer to use SDL for audio output, then its performance is
almost exactly the same as my application’s, when playing 44100Hz audio.

It seems like it is related to rate conversion methods. Unfortunately, after
much searching, I have no idea how to get SDL to use the fastest rate
conversion method (linear interpolation vs. others), or even if such control
is possible.

Any comments or suggestions would be welcome. I hope to avoid configuration
of sound drivers because no such thing is needed by mplayer, so I’m
optimistic in thinking that my app should be able to pull some of the same
tricks.

If someone is going to suggest that I replace SDL’s decoding or audio code
with something else, while retaining the ability to use Mix_PlayMusic, then
this is fine if I can make it easily portable to windows (bundling dll’s or
whatever).

Thanks,

Christian

2

Thats more than just optimism, btw. Its also lots of work. For 5%.
Remember that.

What you’re witnessing is cheap hardware being cheap.
48khz is the playback rate for DVDs. DVD playback needs hardware
acceleration. Those other playback rates aren’t exactly selling
points.

Not really a problem most developers want to deal with.

If mplayer uses every trick in the book to shave percents off the
clock, good for mplayer. Are you writing another mplayer?On Fri, Sep 17, 2010 at 7:40 PM, Christian Leger <chrism.leger at gmail.com> wrote:

I hope to avoid configuration
of sound drivers because no such thing is needed by mplayer, so I’m
optimistic in thinking that my app should be able to pull some of the same
tricks.

3

Hi,

Thanks for the reply.

Good question regarding whether or not I want to write another mplayer. If I
knew how, and had the time, the answer would be yes. But for now it is no.
However, if I let a simple component of a much larger system (a game engine)
eat up 5% just because I haven’t sought advice from people who might know
better than me, then I probably deserve to see every subsystem involved take
up a few percent more than they absolutely have to, and perhaps in the end
the result would be a resource hog that performs under the level that it
could, given the right knowledge. Being a professional and fascinated
programmer, I am definitely in this game for learning as much as to achieve
other aims.

Do you know what types of tricks mplayer is using? My first guess which will
remain a guess until I investigate more closely is that they use SSE or
SSE2+ in their code, whereas perhaps SDL uses mostly plain C. Just a guess,
which I will look into.

If anyone has suggestions as to how I can improve this performance, or how I
can investigate and understand the reason for the performance difference, it
would be greatly appreciated.

Thanks,

ChristianOn Fri, Sep 17, 2010 at 10:57 PM, Jeremiah wrote:

On Fri, Sep 17, 2010 at 7:40 PM, Christian Leger <@Christian_Leger> wrote:

I hope to avoid configuration
of sound drivers because no such thing is needed by mplayer, so I’m
optimistic in thinking that my app should be able to pull some of the
same
tricks.

Thats more than just optimism, btw. Its also lots of work. For 5%.
Remember that.

What you’re witnessing is cheap hardware being cheap.
48khz is the playback rate for DVDs. DVD playback needs hardware
acceleration. Those other playback rates aren’t exactly selling
points.

Not really a problem most developers want to deal with.

If mplayer uses every trick in the book to shave percents off the
clock, good for mplayer. Are you writing another mplayer?

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

4

Why don’t you do a high quality upconvert from 44.1 to 48 using a
commandline tool like “sox”.

sox old.wav -r 48000 new.wav

Remember, on computers speed generally comes from “caching” everything -
this is one form of it. You can then either distribute 48khz audiofiles
only or even both and make a runtime decision which ones to load
depending on the hardware capabilities or a user setting.

Cheers,
AndreasOn 9/17/10 4:40 PM, Christian Leger wrote:

Hi,

After much searching on the internet (more than 10 hours sitting in
front of google results) I continue to be stumped by the problem of
efficient audio rate conversion.

What is needed: to play audio that comes at a sample rate of 44100Hz
on hardware that seems locked at 48000Hz, as fast as possible.

The rough measurements I made are as follows:

My linux system uses alsa.

Any application I use, including my own, to play 44100 audio will
sound fine, but use 4-9% CPU power at all times. Some dedicated audio
player applications use even more.

Mplayer, playing the same audio, reports that the audio is at 44100Hz,
but that alsa is operating at 48000Hz, and uses <0-3% CPU power at all
times. When running with this performance, Mplayer seems to be using
alsa and mp3lib.

If I make my application play the audio at 48000Hz (argument
audio_rate passed to Mix_OpenAudio), then it runs not quite as fast as
Mplayer, but definitely faster than when playing at 44100Hz, as much
as 5% less CPU power in use.

If I tell Mplayer to use SDL for audio output, then its performance is
almost exactly the same as my application’s, when playing 44100Hz audio.

It seems like it is related to rate conversion methods. Unfortunately,
after much searching, I have no idea how to get SDL to use the fastest
rate conversion method (linear interpolation vs. others), or even if
such control is possible.

Any comments or suggestions would be welcome. I hope to avoid
configuration of sound drivers because no such thing is needed by
mplayer, so I’m optimistic in thinking that my app should be able to
pull some of the same tricks.

If someone is going to suggest that I replace SDL’s decoding or audio
code with something else, while retaining the ability to use
Mix_PlayMusic, then this is fine if I can make it easily portable to
windows (bundling dll’s or whatever).

Thanks,

Christian

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

5

Hi,

Thanks for the suggestion. I was looking into that, but I figured questions
about conversions outside my application didn’t quite belong in this mailing
list. It is definitely a viable option. I’m going to give sox a try.

This investigation has actually led me to learn a bit about MMX and SSE
programming, which I’m very happy about. Do any of the SDL libraries make
use of these extensions, or do they harm portability?

Thanks,

ChristianOn Sat, Sep 18, 2010 at 4:04 PM, Andreas Schiffler wrote:

Why don’t you do a high quality upconvert from 44.1 to 48 using a
commandline tool like “sox”.

sox old.wav -r 48000 new.wav

Remember, on computers speed generally comes from “caching” everything -
this is one form of it. You can then either distribute 48khz audiofiles only
or even both and make a runtime decision which ones to load depending on the
hardware capabilities or a user setting.

Cheers,
Andreas

On 9/17/10 4:40 PM, Christian Leger wrote:

Hi,

After much searching on the internet (more than 10 hours sitting in front
of google results) I continue to be stumped by the problem of efficient
audio rate conversion.

What is needed: to play audio that comes at a sample rate of 44100Hz on
hardware that seems locked at 48000Hz, as fast as possible.

The rough measurements I made are as follows:

My linux system uses alsa.

Any application I use, including my own, to play 44100 audio will sound
fine, but use 4-9% CPU power at all times. Some dedicated audio player
applications use even more.

Mplayer, playing the same audio, reports that the audio is at 44100Hz, but
that alsa is operating at 48000Hz, and uses <0-3% CPU power at all times.
When running with this performance, Mplayer seems to be using alsa and
mp3lib.

If I make my application play the audio at 48000Hz (argument audio_rate
passed to Mix_OpenAudio), then it runs not quite as fast as Mplayer, but
definitely faster than when playing at 44100Hz, as much as 5% less CPU power
in use.

If I tell Mplayer to use SDL for audio output, then its performance is
almost exactly the same as my application’s, when playing 44100Hz audio.

It seems like it is related to rate conversion methods. Unfortunately,
after much searching, I have no idea how to get SDL to use the fastest rate
conversion method (linear interpolation vs. others), or even if such control
is possible.

Any comments or suggestions would be welcome. I hope to avoid configuration
of sound drivers because no such thing is needed by mplayer, so I’m
optimistic in thinking that my app should be able to pull some of the same
tricks.

If someone is going to suggest that I replace SDL’s decoding or audio code
with something else, while retaining the ability to use Mix_PlayMusic, then
this is fine if I can make it easily portable to windows (bundling dll’s or
whatever).

Thanks,

Christian

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

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

6

Typically not, but SDL provides an API to check for these CPU
capabilities in SDL_cpuinfo.hOn Sat, Sep 18, 2010 at 2:09 PM, Christian Leger <chrism.leger at gmail.com> wrote:

Hi,

Thanks for the suggestion. I was looking into that, but I figured questions
about conversions outside my application didn’t quite belong in this mailing
list. It is definitely a viable option. I’m going to give sox a try.

This investigation has actually led me to learn a bit about MMX and SSE
programming, which I’m very happy about. Do any of the SDL libraries make
use of these extensions, or do they harm portability?

Thanks,

Christian

On Sat, Sep 18, 2010 at 4:04 PM, Andreas Schiffler wrote:

Why don’t you do a high quality upconvert from 44.1 to 48 using a
commandline tool like “sox”.

sox old.wav -r 48000 new.wav

Remember, on computers speed generally comes from “caching” everything -
this is one form of it. You can then either distribute 48khz audiofiles only
or even both and make a runtime decision which ones to load depending on the
hardware capabilities or a user setting.

Cheers,
Andreas

On 9/17/10 4:40 PM, Christian Leger wrote:

Hi,

After much searching on the internet (more than 10 hours sitting in front
of google results) I continue to be stumped by the problem of efficient
audio rate conversion.

What is needed: to play audio that comes at a sample rate of 44100Hz on
hardware that seems locked at 48000Hz, as fast as possible.

The rough measurements I made are as follows:

My linux system uses alsa.

Any application I use, including my own, to play 44100 audio will sound
fine, but use 4-9% CPU power at all times. Some dedicated audio player
applications use even more.

Mplayer, playing the same audio, reports that the audio is at 44100Hz, but
that alsa is operating at 48000Hz, and uses <0-3% CPU power at all times.
When running with this performance, Mplayer seems to be using alsa and
mp3lib.

If I make my application play the audio at 48000Hz (argument audio_rate
passed to Mix_OpenAudio), then it runs not quite as fast as Mplayer, but
definitely faster than when playing at 44100Hz, as much as 5% less CPU power
in use.

If I tell Mplayer to use SDL for audio output, then its performance is
almost exactly the same as my application’s, when playing 44100Hz audio.

It seems like it is related to rate conversion methods. Unfortunately,
after much searching, I have no idea how to get SDL to use the fastest rate
conversion method (linear interpolation vs. others), or even if such control
is possible.

Any comments or suggestions would be welcome. I hope to avoid
configuration of sound drivers because no such thing is needed by mplayer,
so I’m optimistic in thinking that my app should be able to pull some of the
same tricks.

If someone is going to suggest that I replace SDL’s decoding or audio code
with something else, while retaining the ability to use Mix_PlayMusic, then
this is fine if I can make it easily portable to windows (bundling dll’s or
whatever).

Thanks,

Christian

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

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

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

–
? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

7

If I make my application play the audio at 48000Hz (argument audio_rate
passed to Mix_OpenAudio), then it runs not quite as fast as Mplayer, but
definitely faster than when playing at 44100Hz, as much as 5% less CPU power
in use.

Plain audio mixing in SDL used to be done in mmx, but due to a bug in
the code the mmx routines were disabled. I wrote a patch a while back
to fix it because I needed the extra performance (I was writing a game
for the OLPC platform). I submitted it in this e-mail:
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2010-July/077225.html
, maybe it can help you a little bit.On Fri, Sep 17, 2010 at 8:40 PM, Christian Leger <chrism.leger at gmail.com> wrote:

Hi,

After much searching on the internet (more than 10 hours sitting in front of
google results) I continue to be stumped by the problem of efficient audio
rate conversion.

What is needed: to play audio that comes at a sample rate of 44100Hz on
hardware that seems locked at 48000Hz, as fast as possible.

The rough measurements I made are as follows:

My linux system uses alsa.

Any application I use, including my own, to play 44100 audio will sound
fine, but use 4-9% CPU power at all times. Some dedicated audio player
applications use even more.

Mplayer, playing the same audio, reports that the audio is at 44100Hz, but
that alsa is operating at 48000Hz, and uses <0-3% CPU power at all times.
When running with this performance, Mplayer seems to be using alsa and
mp3lib.

If I make my application play the audio at 48000Hz (argument audio_rate
passed to Mix_OpenAudio), then it runs not quite as fast as Mplayer, but
definitely faster than when playing at 44100Hz, as much as 5% less CPU power
in use.

If I tell Mplayer to use SDL for audio output, then its performance is
almost exactly the same as my application’s, when playing 44100Hz audio.

It seems like it is related to rate conversion methods. Unfortunately, after
much searching, I have no idea how to get SDL to use the fastest rate
conversion method (linear interpolation vs. others), or even if such control
is possible.

Any comments or suggestions would be welcome. I hope to avoid configuration
of sound drivers because no such thing is needed by mplayer, so I’m
optimistic in thinking that my app should be able to pull some of the same
tricks.

If someone is going to suggest that I replace SDL’s decoding or audio code
with something else, while retaining the ability to use Mix_PlayMusic, then
this is fine if I can make it easily portable to windows (bundling dll’s or
whatever).

Thanks,

Christian

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

8

Thanks, I will see if I can give that a try.On Sun, Sep 19, 2010 at 10:49 PM, Felipe <felipe.otamendi at gmail.com> wrote:

If I make my application play the audio at 48000Hz (argument audio_rate
passed to Mix_OpenAudio), then it runs not quite as fast as Mplayer, but
definitely faster than when playing at 44100Hz, as much as 5% less CPU
power
in use.

Plain audio mixing in SDL used to be done in mmx, but due to a bug in
the code the mmx routines were disabled. I wrote a patch a while back
to fix it because I needed the extra performance (I was writing a game
for the OLPC platform). I submitted it in this e-mail:
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2010-July/077225.html
, maybe it can help you a little bit.

On Fri, Sep 17, 2010 at 8:40 PM, Christian Leger <@Christian_Leger> wrote:

Hi,

After much searching on the internet (more than 10 hours sitting in front
of
google results) I continue to be stumped by the problem of efficient
audio
rate conversion.

What is needed: to play audio that comes at a sample rate of 44100Hz on
hardware that seems locked at 48000Hz, as fast as possible.

The rough measurements I made are as follows:

My linux system uses alsa.

Any application I use, including my own, to play 44100 audio will sound
fine, but use 4-9% CPU power at all times. Some dedicated audio player
applications use even more.

Mplayer, playing the same audio, reports that the audio is at 44100Hz,
but
that alsa is operating at 48000Hz, and uses <0-3% CPU power at all times.
When running with this performance, Mplayer seems to be using alsa and
mp3lib.

If I make my application play the audio at 48000Hz (argument audio_rate
passed to Mix_OpenAudio), then it runs not quite as fast as Mplayer, but
definitely faster than when playing at 44100Hz, as much as 5% less CPU
power
in use.

If I tell Mplayer to use SDL for audio output, then its performance is
almost exactly the same as my application’s, when playing 44100Hz audio.

It seems like it is related to rate conversion methods. Unfortunately,
after
much searching, I have no idea how to get SDL to use the fastest rate
conversion method (linear interpolation vs. others), or even if such
control
is possible.

Any comments or suggestions would be welcome. I hope to avoid
configuration
of sound drivers because no such thing is needed by mplayer, so I’m
optimistic in thinking that my app should be able to pull some of the
same
tricks.

If someone is going to suggest that I replace SDL’s decoding or audio
code
with something else, while retaining the ability to use Mix_PlayMusic,
then
this is fine if I can make it easily portable to windows (bundling dll’s
or
whatever).

Thanks,

Christian

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

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