[Draft] Enhanced Audio Converter, 1/4 (repost)

Hi,

while using SDL for enabling audio in my application,
I see the opportunity to enhance the quality of the
audio converter (SDL_AudioCVT).
Currently the sample rate conversion is done by using
doubling every sample for up-conversion, or using
every second sample for down-conversion. This, while
working really fast, has the drawback of not taking
aliasing into account.
Here is an example: consider a sinus signal of 3.9 kHz
with a sample rate of 8kHz. If we change the sample
rate to 16 kHz with the algorithm mentioned above, we
got two signals, one with 3.9 kHz which is desired and
one with 4.1 kHz which is an aliasing artefact and
should be rejected.
In the enhanced audio converter this rejection is done
with an appropiate filter with an cut off frequence at
4 kHz, a quarter of the new sampling frequence.
For down-conversion, the signal is filtered first, and
the every second sample is taken.

The filter is implemented as a FIR structure to maintain
the orignal signal phase. If the ratio between source and
destination rate is larger then 2, the process is broken
into steps to get a high cutoff slope and achieve low
computational load.

The conversation between abbitrary samplerates is done,
by approximate the ratio of src and dst rate by a
fraction n/d where an n,d < 17. This results in a
perfect match fo sample rate conversation 32kHz<->48kHz,
and and minor error of 0.3% for e.g. 44.1kHz<->48kHz
or 44.1kHz<->32kHz. The fraction has to be small, because
we need a representation of each filter precalculated.
So, if we use the 44.1->48 example above, which is
approximated by 12/11, we need 12 coefficient sets,
in the other direction we need 11 coefficient sets.

To avoid the implementation of the filter for every
sample-format, the structure of of the AudioCVT is
modified. In a first step the sample format is converted
to signed short, the second step changes the sample
rate, and the final step converts to the desired
destination format. The remaining targets for the filter
a mono and stereo format, which are taken care by a
template-like implementation, for maximum speed.

Finally the filter can work in two modes, one is called
Looped while the other is straight. Filter corrolate
samples before and after the actual one. Therefore, is
a looped signal is considered, the samples after the
end are the beginning ones, while in the straigt case
they are simply zeroes.

I the following mail the SDL_audio_converter.c, and to the
third and fourth mail the header files filter_templates.h
and SDL_audio_converter.h. While these files compile, no
test is perfomed, so it is unlikely that they are working
right now.
May I ask you to comment on the coding style and on
compatibilty issues? Is it likely that this code is included
in the SDL?

Yours,

Frank

while using SDL for enabling audio in my application,
I see the opportunity to enhance the quality of the
audio converter (SDL_AudioCVT).

(Almost a month later…)

I’ve taken these routines and plugged them into SDL_sound, so that they
can be optionally compiled into the library to replace the code we
originally pulled out of SDL.

This proves to be a fairly convenient testbed for the conversion routines.

I chopped them up a little to make their interface more like the original
SDL API, so that I can build SDL_sound with either library. A couple of
other things were changed and tweaked. Nothing major, but there are some
noticable changes in there.

Right now, it doesn’t work very well, but it’s possible I’ve broken
something while tweaking it.

For those that are interested in trying this, pull the latest from
SDL_sound’s CVS (instructions at http://icculus.org/SDL_sound/), and pass
–enable-altcvt to the ./configure script. The best way to test it is to
use the included playsound program:

playsound --rate 8000 --channels 1 --format S16LSB soundfile.ext

(the 8000, 1, S16LSB represent what you want to convert soundfile.ext to
on-the-fly while playing it. The file itself can be in whatever format.)

I’m interested in getting this working and included with the upcoming
SDL_sound v1.0, so patches are very welcome. Get on the mailing list;
instructions are at the website.

Also, Frank, if you’ve improved this code in the past month, I’d like to
get a newer version of it.

Theoretically, once we stabilize this code through SDL_sound, we could
transplant it into SDL (for 2.0?).

Thanks,
–ryan.

Theoretically, once we stabilize this code through SDL_sound, we could
transplant it into SDL (for 2.0?).

Yep. :slight_smile:

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

Hi,

first I want to thank you for reviewing my code.

Right now, it doesn’t work very well, but it’s possible I’ve broken
something while tweaking it.

Sorry for not being not clear at this issue, it was not supposed to work.

I intended to get a feedback, whether the coding style is ok, whether the
interface matches your expectations, and if you interested in that kind of
improvements at all, before putting much time into it.

Theoretically, once we stabilize this code through SDL_sound, we could
transplant it into SDL (for 2.0?).

It is nice to hear this.

I’ve taken these routines and plugged them into SDL_sound, so that they
can be optionally compiled into the library to replace the code we
originally pulled out of SDL.

I chopped them up a little to make their interface more like the original
SDL API, so that I can build SDL_sound with either library. A couple of
other things were changed and tweaked. Nothing major, but there are some
noticable changes in there.
I’ll take this changes back in my code. I’ll address the ‘fixme’, too.
I am not sure about the Sint16, maybe we should use an audio_t, which
is Sint16 for now, but gives us the option to use float as an alternative.

I’m interested in getting this working and included with the upcoming
SDL_sound v1.0, so patches are very welcome. Get on the mailing list;
instructions are at the website.

I’ll join the mailing list. When do you plan to release SDL_sound?

Also, Frank, if you’ve improved this code in the past month, I’d like to
get a newer version of it.

I fixed the more obviously bugs, but I am not satisfied with the design
of variable_rate_converter.

For the moment I’ve got an contract, which takes up my spare time. But
hopefully I can come back to the converter at the beginning of next week.

Yours,

Frank

Sorry for not being not clear at this issue, it was not supposed to work.

I understand, I was just hoping it would. :slight_smile:

I’ll join the mailing list. When do you plan to release SDL_sound?

The sooner the better. The TODO file with SDL_sound has details of what
I’d like to do before releasing 1.0. Since the alternate conversion
routines are disabled by default, I don’t see a need to hold up a 1.0
release for them; if they are working by then, wonderful, but if not, we
can continue to work on them after 1.0.

For the moment I’ve got an contract, which takes up my spare time. But
hopefully I can come back to the converter at the beginning of next week.

Cool. There’re some other people that want to work with the code, too, so
be sure to check CVS for updates in case any fixes have landed in the
meantime.

–ryan.