A dumb question, I know… but I figure you guys know as much about this
sort of stuff as anyone.
My current WAV-playing code plays quite well, but there is a very slight
static/crackle in the background (not a lot, but noticable if you listen
carefully). I am playing a 44.1kHz WAV, but my chip wants samples at
48kHz. Would that be a likely cause of the background noise?
Assuming I can’t change the rate of the chip, any ideas where I would find
information on how to convert from 44.1 to 48? Apologies for the slightly
off topic subject… thanks a lot.–
Craig Edwards
I’m not an audio person, but could it be possible that you
are using a lot of digital PCM volume amplification in your
sound mixer? You might try turning the digital PCM
amplification down, and turn the analog amplification up on
your speakers and see what happens.
Just a thought.
Paul Lowe
pauls_lists at tetravista.netOn Tuesday 26 October 2004 02:13 am, Craig Edwards wrote:
A dumb question, I know… but I figure you guys know as
much about this sort of stuff as anyone.
My current WAV-playing code plays quite well, but there
is a very slight static/crackle in the background (not a
lot, but noticable if you listen carefully). I am
playing a 44.1kHz WAV, but my chip wants samples at
48kHz. Would that be a likely cause of the background
noise?
Assuming I can’t change the rate of the chip, any ideas
where I would find information on how to convert from
44.1 to 48? Apologies for the slightly off topic
subject… thanks a lot.
It is certainly possible, although I am not actually using a mixer, per
se. I am just dumping the raw WAV data to the chip, so I guess I am using
whatever its volume settings are. Its a good thought though… I will do
some fiddling with the volume registers tonight. Thanks for the
suggestion.On Tue, 26 Oct 2004 07:45:40 -0700, Paul Lowe <pauls_lists at tetravista.net> wrote:
I’m not an audio person, but could it be possible that you
are using a lot of digital PCM volume amplification in your
sound mixer? You might try turning the digital PCM
amplification down, and turn the analog amplification up on
your speakers and see what happens.
–
Craig Edwards
Dude, I’m basically referring to the sound card volume
settings available on your operating system. Usually there
is a main volume, a PCM volume, a CD-ROM audio volume, a
MIDI sequencer volume, and so on…
You might try turning the PCM volume down very low, and then
turn the analog volume way up on your speakers. I do not
exactly understand why or how this works, even though I am
an electrical engineering student, I believe it has to do
with how digital amplification works in terms of its’
finite limitations, versus analog amplification which is a
lot smoother.
Kind Regards,
Paul Lowe
pauls_lists at tetravista.netOn Tuesday 26 October 2004 02:55 pm, Craig Edwards wrote:
On Tue, 26 Oct 2004 07:45:40 -0700, Paul Lowe <pauls_lists at tetravista.net> wrote:
I’m not an audio person, but could it be possible that
you are using a lot of digital PCM volume amplification
in your sound mixer? You might try turning the digital
PCM amplification down, and turn the analog
amplification up on your speakers and see what happens.
It is certainly possible, although I am not actually
using a mixer, per se. I am just dumping the raw WAV
data to the chip, so I guess I am using whatever its
volume settings are. Its a good thought though… I will
do some fiddling with the volume registers tonight.
Thanks for the suggestion.
He he he… I see the confusion. I am actually writing an audio driver
for an audio chip that has no operating system (or at least, not one like
you are thinking). There is no volume application, no mixer, no
nothing… just my code 
So, if I want to adjust the volume, I need to
poke around in the audio chip registers.
Nonetheless, I still think your suggestion may have some merit. I will
give it a go tonight.On Tue, 26 Oct 2004 08:18:22 -0700, Paul Lowe <pauls_lists at tetravista.net> wrote:
Dude, I’m basically referring to the sound card volume
settings available on your operating system. Usually there
is a main volume, a PCM volume, a CD-ROM audio volume, a
MIDI sequencer volume, and so on…
–
Craig Edwards
Le Tue, 26 Oct 2004 19:13:38 +1000
"Craig Edwards" a ?crit:
My current WAV-playing code plays quite well, but there is a very slight
static/crackle in the background (not a lot, but noticable if you listen
carefully). I am playing a 44.1kHz WAV, but my chip wants samples at
48kHz. Would that be a likely cause of the background noise?
Having a different replay frequency just change the pitch of your sample.
In your case, it replays the sample faster than it should be. A small
crackle could be caused by the fact that your replay is not continuous:
i.e. there is a very small pause between the replay of the audio buffers
by the hardware. Do you restart your replay each time you have a buffer to
play, or does your hardware can play buffers in a repeat mode ? Also if
you are double (or multi) buffering your audio, be sure to not calculate a
buffer your hardware is currently replaying.
Assuming I can’t change the rate of the chip, any ideas where I would
find information on how to convert from 44.1 to 48? Apologies for the
slightly off topic subject… thanks a lot.
See the various modules (.mod, .xm, .s3m, etc…) replay routines, like
libmikmod. This is the base of a module replay routine, to be able to play
a sample at different notes. Check virtch*.c in libmikmod/playercode subdir.
A subset of libmikmod is present in SDL_Mixer.–
Patrice Mandin
WWW: http://membres.lycos.fr/pmandin/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux
The XBOX audio chip is AC97 compliant. It has 32 “descriptors”; each of
which contain a pointer to an audio sample fragment and some control
flags. When it has finished playing a fragment, it triggers an interrupt
(depending on the value of the control flags), and then starts playing
whatever the next descriptor is pointing to. When it finishes the last
descriptor, it just rolls around to the first one again. So,
theoretically all my driver has to do is feed data into the memory
locations that the descriptors are pointing to in a timely fashion.
I thought I had ruled out timing issues because I setup data in 3 fragment
buffers (and their descriptors) and then start playing. The chip plays
the first fragment, triggers an interrupt and then starts playing the
second one. While it is playing the second one, my driver handles the
interrupt and starts populating the fourth one. When the chip finishes
playing the second fragment, it triggers an interrupt and starts playing
the third fragment. My driver then gets the 5th fragment, and so on… in
this fashion, I was hoping to avoid any “gaps” where the chip has to wait
for the driver to get more data. Perhaps my code is a bit dodgy… I will
go back and review.
Thanks again for your thoughts.On Fri, 29 Oct 2004 16:53:58 +0200, Patrice Mandin <mandin.patrice at wanadoo.fr> wrote:
… A small
crackle could be caused by the fact that your replay is not continuous:
i.e. there is a very small pause between the replay of the audio buffers
by the hardware. Do you restart your replay each time you have a buffer
to
play, or does your hardware can play buffers in a repeat mode ? Also if
you are double (or multi) buffering your audio, be sure to not calculate
a
buffer your hardware is currently replaying.
–
Craig Edwards
Craig Edwards wrote:> On Fri, 29 Oct 2004 16:53:58 +0200, Patrice Mandin <mandin.patrice at wanadoo.fr> wrote:
… A small
crackle could be caused by the fact that your replay is not continuous:
i.e. there is a very small pause between the replay of the audio buffers
by the hardware. Do you restart your replay each time you have a
buffer to
play, or does your hardware can play buffers in a repeat mode ? Also if
you are double (or multi) buffering your audio, be sure to not
calculate a
buffer your hardware is currently replaying.
The XBOX audio chip is AC97 compliant. It has 32 “descriptors”; each
of which contain a pointer to an audio sample fragment and some
control flags. When it has finished playing a fragment, it triggers
an interrupt (depending on the value of the control flags), and then
starts playing whatever the next descriptor is pointing to. When it
finishes the last descriptor, it just rolls around to the first one
again. So, theoretically all my driver has to do is feed data into
the memory locations that the descriptors are pointing to in a timely
fashion.
I thought I had ruled out timing issues because I setup data in 3
fragment buffers (and their descriptors) and then start playing. The
chip plays the first fragment, triggers an interrupt and then starts
playing the second one. While it is playing the second one, my
driver handles the interrupt and starts populating the fourth one.
When the chip finishes playing the second fragment, it triggers an
interrupt and starts playing the third fragment. My driver then gets
the 5th fragment, and so on… in this fashion, I was hoping to avoid
any “gaps” where the chip has to wait for the driver to get more
data. Perhaps my code is a bit dodgy… I will go back and review.
So with your current scheme, you are only 1 or 2 fragments ahead of the
sound card ? That doesn’t seem like much to me, so that might be one cause.
Other than that, what do you want the 44kHz -> 48kHz conversion for ? In
the case of an SDL audio driver, SDL is supposed to be doing the
conversion, but it’s buggy. Try to flip the #if 1 in SDL_audiocvt.c:1528
and see if it works better. As you see in the comment, there is no good
way of supporting the change in sampling.
IMO, the golden bullet is really to have the card work at 44kHz.
However, depending on the AC97 implementation present in the XBOX, this
might or might not be present.
Stephane
Stephane Marchesin wrote:
Craig Edwards wrote:
… A small
crackle could be caused by the fact that your replay is not continuous:
i.e. there is a very small pause between the replay of the audio buffers
by the hardware. Do you restart your replay each time you have a
buffer to
play, or does your hardware can play buffers in a repeat mode ? Also if
you are double (or multi) buffering your audio, be sure to not
calculate a
buffer your hardware is currently replaying.
The XBOX audio chip is AC97 compliant. It has 32 “descriptors”; each
of which contain a pointer to an audio sample fragment and some
control flags. When it has finished playing a fragment, it triggers
an interrupt (depending on the value of the control flags), and then
starts playing whatever the next descriptor is pointing to. When it
finishes the last descriptor, it just rolls around to the first one
again. So, theoretically all my driver has to do is feed data into
the memory locations that the descriptors are pointing to in a timely
fashion.
I thought I had ruled out timing issues because I setup data in 3
fragment buffers (and their descriptors) and then start playing. The
chip plays the first fragment, triggers an interrupt and then starts
playing the second one. While it is playing the second one, my
driver handles the interrupt and starts populating the fourth one.
When the chip finishes playing the second fragment, it triggers an
interrupt and starts playing the third fragment. My driver then gets
the 5th fragment, and so on… in this fashion, I was hoping to avoid
any “gaps” where the chip has to wait for the driver to get more
data. Perhaps my code is a bit dodgy… I will go back and review.
So with your current scheme, you are only 1 or 2 fragments ahead of the
sound card ? That doesn’t seem like much to me, so that might be one cause.
Other than that, what do you want the 44kHz -> 48kHz conversion for ? In
the case of an SDL audio driver, SDL is supposed to be doing the
conversion, but it’s buggy. Try to flip the #if 1 in SDL_audiocvt.c:1528
and see if it works better. As you see in the comment, there is no good
way of supporting the change in sampling.
IMO, the golden bullet is really to have the card work at 44kHz.
However, depending on the AC97 implementation present in the XBOX, this
might or might not be present.
And to make things even more interesting, depending on the exact AC97
hardware and on the driver version, sometimes the chip will not report
an error when one requests a sampling rate that it does not support.
We had such problems with AC97 that nowadays we disable it in BIOS on
any PC with one…>> On Fri, 29 Oct 2004 16:53:58 +0200, Patrice Mandin <mandin.patrice at wanadoo.fr> wrote:
Stephane
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41
So with your current scheme, you are only 1 or 2 fragments ahead of the
sound card ? That doesn’t seem like much to me, so that might be one
cause.
I will try with a few more fragments and see what happens…
Other than that, what do you want the 44kHz -> 48kHz conversion for ? In
the case of an SDL audio driver, SDL is supposed to be doing the
conversion, but it’s buggy.
Ahh… but I haven’t got my SDL implementation working yet! I get the
crackling using just the raw driver, so I was wondering if the 44kHz/48kHz
disparity might be the cause of it. As another poster said, though, that
difference should just result in a slightly faster playback.
Try to flip the #if 1 in SDL_audiocvt.c:1528 and see if it works better.
As you see in the comment, there is no good way of supporting the change
in sampling.
IMO, the golden bullet is really to have the card work at 44kHz.
However, depending on the AC97 implementation present in the XBOX, this
might or might not be present.
Ahhh… I didn’t know you could ask the chip to change. I will do some
more reading of the spec and see what registers I need to modify. Thanks
for the suggestion.On Tue, 02 Nov 2004 13:24:05 +0100, Stephane Marchesin <stephane.marchesin at wanadoo.fr> wrote:
–
Craig Edwards