23 Oct
2005
23 Oct
'05
9:09 p.m.
The code looping over the samples appears to be fine. As I mentioned,
there is no problems with stereo or 44100 samples. The file format is
correct since I created the file myself. It is definately 16-bit, mono,
22050, and only this format has the noise.
This is basically the code for fading up (in Pascal).
FadeSpeed := 2000; // milliseconds
FadeBytes := Round(SampleRate * Channels / 1000 * FadeSpeed);
ByteCount := 0;
for i := 0 to (BufferSize shr 1) -1 do
begin
Inc(ByteCount);
if ByteCount >= FadeBytes then CurrVol := 32767
else CurrVol := ByteCount / FadeBytes;
Buffer16[i] := Buffer16[i] * CurrVol / 32767;
end;
Buffer16 is an array of 16-bit integer (ShortInt in Pascal). BufferSize
is the size in bytes of the audio buffer containing raw audio.
To answer Sampo's question, the fades are gradule over periods like 2
seconds.
However, I've also tested ith a constant faded volume. eg CurrVol stays
constant at one value. The problem still occurs. It's got me stumped,
considering that stereo samples work fine and yet the only difference is
that it works over double the number of bytes.
Ross.
----- Original Message -----
From: "fons adriaensen" <fons.adriaensen(a)skynet.be>
To: "The Linux Audio Developers' Mailing List"
<linux-audio-dev(a)music.columbia.edu>
Sent: Monday, October 24, 2005 12:14 AM
Subject: Re: [linux-audio-dev] 22050hz mono volume fading
On Sun, Oct 23, 2005 at 10:55:49PM +1300, Ross Levis wrote:
The basic equation I'm doing is (Excuse the Pascal
syntax):
Data := Data * CurrVol / 32767;
Data is always 2 bytes of audio data (16 bit data). CurrVol goes from
0
to 32767 or vice
versa over several bytes. If I remove this line, there is no noise
generated, but
obviously no volume change either.
The problem only occurs when it's mono 22050 samples. Stereo 22050
samples are fine, and mono 44100 samples are fine.
The problem is clearly not with the line you posted, but with how
it is used, i.e. in the code that loops over the samples. Or the
sample format of your mono 22k05 source is not what you think it
is. For example if its just 8 bits instead of 16 you could get
an effect similar to what you describe.
--
FA