soundcard buffer format

RV <do_not_use@email.com> writes:

> On Fri, 24 Dec 2004 12:28:55 -0500, Jerry Avins <jya@ieee.org> wrote:
>
>>RV wrote:
>>
>>  ...
>>
>>> At some point do you guys thinkl you can stick to windows multimedia
>>> API's and forget the lesson on a whole lotta "stuff" that means
>>> nothing to the guy whio is trying to worte to code in win mm API code.
>>
>>Simplifying is appropriate. Misinforming is not.
>
> Uh huh
> So
> Do you know the code used in Win32 mm API to do what the OP needs to
> do or not?

I responded with exactly this information a few days ago but no one seemed to care:

http://groups-beta.google.com/group/comp.multimedia/msg/0a87318d38ea41eb?dmode=source

--RY


-- 
%  Randy Yates                  % "The dreamer, the unwoken fool - 
%% Fuquay-Varina, NC            %  in dreams, no pain will kiss the brow..."
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Eldorado Overture', *Eldorado*, ELO
http://home.earthlink.net/~yatescr

On Fri, 24 Dec 2004 12:28:55 -0500, Jerry Avins <jya@ieee.org> wrote:

>RV wrote:
>
>  ...
>
>> At some point do you guys thinkl you can stick to windows multimedia
>> API's and forget the lesson on a whole lotta "stuff" that means
>> nothing to the guy whio is trying to worte to code in win mm API code.
>
>Simplifying is appropriate. Misinforming is not.

Uh huh
So
Do you know the code used in Win32 mm API to do what the OP needs to
do or not?

On Thu, 23 Dec 2004 18:10:08 +0100, Stephan M. Bernsee
<spam@dspdimension.com> wrote:

>On 2004-12-23 15:59:48 +0100, RV <do_not_use@email.com> said:
>
>> Jerry was right
>> 16 bit describes the size, not the rate
>
>Yes. And I was adding that for one channel, sample size * sample rate = bit rate.

Not used in Win API audio coding.

>
>> I used bit rate in the begining and I was wrong, he was right.
>> 16 bit means the is Bit "size".
>> 8 bit means the Bit "size".
>
>No, it doesn't. A bit has always a size of exactly 1.
>16 bit or 8 bit is the word length for your samples.

Un huh

Well for you then Ill shuffle it again.

16 bit means the is "size" in bits.
8 bit means the "size" in bits.

Let me know if that still not self evident Ill try holding my toungue
in the other direction when I post the reply.

>
>> You corrected him by saying that is the Bit rate.?
>
>No. The bit rate is the number of bits that go to the D/A per second. 
>That's what I wrote in my last post.

Uh huh
But how does that answer the question

"You corrected him by saying that is the Bit "rate".?"

>
>> bit per sec describes the "rate"
>> 16 bit and 8 bit refers only othe the size as he said.
>
>See my last posting - that's exactly what I said, too!

He said
~~~~~
> Most people I know would call that size, not rate. Is rate commonly used
> that way among some groups?
> 
> Jerry

~~~~~~

To which you said

~~~~~~
I hope not!

Bit rate generally means the number of bits/sec.  Of course, for a 
change in sample rate this number changes, too.

~~~~~

rate was wrong
size was right.

>
>> "bit rate" is used in compressed audio not PCM wave and was used by me
>> to begin with incorrectly.
>
>"Bit rate" can be used for non-compressed audio as well. Like I said, 
>it just describes the number of bits that pass through your buffer per 
>second.

Not in Win API audio code.
Thats what the OP is using.

>
>> Last time I make that mistake on Usenet..
>
>Don't worry - making mistakes is a good thing! I do it all the time.
>:-)
>
>> When I wrote use samples per sec I mean use samples per sec in
>> preference to bit per sec when specifying rate for a PCM wave file
>> becuase thats what is used in PCM wave code.
>> Not bit per sec.
>
>That's a matter of naming convention. You can use both units, but they 
>mean different things.

Not in Win API audio code
Apples aint oranges.
The API code for PCM wave is the API code for PCM wave

>
>>> You store your data points (your SAMPLES) as numbers of a certain WORD 
>>> LENGTH (typically 8, 16, 24, 32 BITS each) collected a certain SAMPLE 
>>> RATE (typically specified as samples/sec). Also, you are usually 
>>> dealing with FRAMES which contain a certain number of samples per 
>>> channel. For a stereo recording, each frame contains 2 samples, left 
>>> and right.
>> 
>> You might refer to them as frames but the WAVE structure doesnt so to
>> call a stereo pair of samples a frame doesnt equate to what the OP is
>> trying to do, which is write the code for WAVE.
>
>Yes I agree. Now I see our problem: you were talking about that WAVE 
>structure and how things are called therein. You should be aware that 
>M$ never actually cared a great deal about correct naming or sensible 
>units, obviously. Maybe that's part of the confusion here.

The only confustion is when some people use terms not used in the code
that is to be wrritten by the OP.
Thats Win32 MM API code.

>
>>> Nope, the minimum level for signed 16 bit data is -32768, not -32767.
>> 
>> -32768 might be the "minimum" level of a signed integer.
>> (do you mean, the minimum "value" for a signed integer ?)
>
>Sure. The minimum value, or the most negative value, or the audio level 
>corresponding to the most negative value.

And that audio level is?

>
>> Im refering to the number of audio "levels" each side of 0 to show
>> that 0 is the lowest audio level.
>
>Right, zero is zero. No doubt about it. ;-)
>
>> But if it your wish it, make that.
>> 
>> The range is
>> 0 -32768
>> and
>> 0 +32768
>
>No again, a value of +32768 would wrap around. Either you are talking 
>about values, in which case your values go from -32768 to +32767 or 
>you're talking about a *range*, which is always a positive number

Uhh huh
Well back to Win API audio coding.

We dont have -32768 and +32767 as the peak values of audio level.

In Win API audio code. we have 2 peak signed values of the same order
of scale, each side of 0

On 2004-12-23 15:59:48 +0100, RV <do_not_use@email.com> said:

> Jerry was right
> 16 bit describes the size, not the rate

Yes. And I was adding that for one channel, sample size * sample rate = 
bit rate.

> I used bit rate in the begining and I was wrong, he was right.
> 16 bit means the is Bit "size".
> 8 bit means the Bit "size".

No, it doesn't. A bit has always a size of exactly 1.
16 bit or 8 bit is the word length for your samples.

> You corrected him by saying that is the Bit rate.?

No. The bit rate is the number of bits that go to the D/A per second. 
That's what I wrote in my last post.

> bit per sec describes the "rate"
> 16 bit and 8 bit refers only othe the size as he said.

See my last posting - that's exactly what I said, too!

> "bit rate" is used in compressed audio not PCM wave and was used by me
> to begin with incorrectly.

"Bit rate" can be used for non-compressed audio as well. Like I said, 
it just describes the number of bits that pass through your buffer per 
second.

> Last time I make that mistake on Usenet..

Don't worry - making mistakes is a good thing! I do it all the time.
:-)

> When I wrote use samples per sec I mean use samples per sec in
> preference to bit per sec when specifying rate for a PCM wave file
> becuase thats what is used in PCM wave code.
> Not bit per sec.

That's a matter of naming convention. You can use both units, but they 
mean different things.

>> You store your data points (your SAMPLES) as numbers of a certain WORD 
>> LENGTH (typically 8, 16, 24, 32 BITS each) collected a certain SAMPLE 
>> RATE (typically specified as samples/sec). Also, you are usually 
>> dealing with FRAMES which contain a certain number of samples per 
>> channel. For a stereo recording, each frame contains 2 samples, left 
>> and right.
> 
> You might refer to them as frames but the WAVE structure doesnt so to
> call a stereo pair of samples a frame doesnt equate to what the OP is
> trying to do, which is write the code for WAVE.

Yes I agree. Now I see our problem: you were talking about that WAVE 
structure and how things are called therein. You should be aware that 
M$ never actually cared a great deal about correct naming or sensible 
units, obviously. Maybe that's part of the confusion here.

>> Nope, the minimum level for signed 16 bit data is -32768, not -32767.
> 
> -32768 might be the "minimum" level of a signed integer.
> (do you mean, the minimum "value" for a signed integer ?)

Sure. The minimum value, or the most negative value, or the audio level 
corresponding to the most negative value.

> Im refering to the number of audio "levels" each side of 0 to show
> that 0 is the lowest audio level.

Right, zero is zero. No doubt about it. ;-)

> But if it your wish it, make that.
> 
> The range is
> 0 -32768
> and
> 0 +32768

No again, a value of +32768 would wrap around. Either you are talking 
about values, in which case your values go from -32768 to +32767 or 
you're talking about a *range*, which is always a positive number. The 
range for both signed and unsigned 16 bit integers is 65536 different 
numeric values, or possible amplitude levels.

It's not that this is my wish, it's just how things are.
-- 
Stephan M. Bernsee
http://www.dspdimension.com

On Wed, 22 Dec 2004 20:33:54 +0100, Stephan M. Bernsee
<spam@dspdimension.com> wrote:

>On 2004-12-22 14:36:51 +0100, RV <do_not_use@email.com> said:
>
>> On Wed, 22 Dec 2004 07:44:54 +0100, Stephan M. Bernsee
>> <spam@dspdimension.com> wrote:
>> 
>>> I hope not!
>>> 
>>> Bit rate generally means the number of bits/sec.  Of course, for a 
>>> change in sample rate this number changes, too.
>> 
>> Not quite, bit rate is the "rate" of bits over time.
>
>That's what I said, is it not?


As far as I know this is what was said
~~~~~~~
>> Most people I know would call that size, not rate. Is rate commonly used
>> that way among some groups?
>> 
>> Jerry

>I hope not!

>Bit rate generally means the number of bits/sec.  Of course, for a 
>change in sample rate this number changes, too.
~~~~~~~~~

Jerry was right
16 bit describes the size, not the rate

I used bit rate in the begining and I was wrong, he was right.
16 bit means the is Bit "size".
8 bit means the Bit "size".

You corrected him by saying that is the Bit rate.?

bit per sec describes the "rate"
16 bit and 8 bit refers only othe the size as he said.

"bit rate" is used in compressed audio not PCM wave and was used by me
to begin with incorrectly.
Last time I make that mistake on Usenet..

>
>> "16 bit" or "8 bit" simply represents the block size in bits of each
>> sample, it doesn't describe time.
>
>Yes - again that's what I said.
>
>> For bit per sec I suggest it's best to refer to wave as samples per
>> sec.
>
>Samples per sec doesn't say anything about the word length of the 
>samples, this is something different. IOW: "samples per sec" does not 
>define "bits per sec" without knowing the word length.

When I wrote use samples per sec I mean use samples per sec in
preference to bit per sec when specifying rate for a PCM wave file
becuase thats what is used in PCM wave code.
Not bit per sec.

>
>Again, to recap:
>
>You store your data points (your SAMPLES) as numbers of a certain WORD 
>LENGTH (typically 8, 16, 24, 32 BITS each) collected a certain SAMPLE 
>RATE (typically specified as samples/sec). Also, you are usually 
>dealing with FRAMES which contain a certain number of samples per 
>channel. For a stereo recording, each frame contains 2 samples, left 
>and right.

You might refer to them as frames but the WAVE structure doesnt so to
call a stereo pair of samples a frame doesnt equate to what the OP is
trying to do, which is write the code for WAVE.
So if he uses samples and blocks for wave it might make more sense
looking at the structure in code..


This is the WAVEFORMATstructure, Im sure youve seen it before.

   FormatTag
   Channels
   SamplesPerSec
   AvgBytesPerSec
   BlockAlign
   BitsPerSample

 no frames

Blocks and Samples
BitsPerSample describes block size in bits.
And a Block is the BitsPerSample multiplied by number of channels

For rate, which none of the above describe
Samples per sec

AvgByte per sec comes close to "bit per sec" being it describes the
rate and bits via bytes, but "bit per sec" isnt use in PCM wave code.

"bit per sec" is used in code for compression encoded audio like MPEG

And no frames anywhere in the code for PCM wave.

Not in WAVEHDR, WAVEINCAPS or WAVEOUTCAPS

If you want to use "frames" see the description for any compression
encoded audio like MPEG, where you will find your "frames" in the
terminology of the code used.

See  MPEGLAYER3WAVEFORMAT

FramesPerBlock

So there are your Frames in MPEG compression encoded files.

But "Frames" isnt used in the PCM wave code anywhere.

So to be of most help to the OP with his code lets not put "Frames"
where "Frames" are not used or needed.

Me mentioning "bit rate" to begin with has caused enough confusion
already I think.

>
>The BIT RATE would then be the total number of bits shuffled to the D/A 
>converters (or any other device in the signal chain) in each second 
>that passes.

True but we are refering to the levels of each sample, or thats what
the Jerry pointed out and in fact the OP did ask.

Wanting to know the scale or "bit size" that applies to audio level
incoming.
For a change in sample rate.


> This rate would consequently be the product of the word 
>length of the samples, the sample rate and the frame size (ie. number 
>of channels) over one second.

Yeah but Block size for PCM wave.

Or BlockAlign
number of channels multiplied by bytes per sample.

What you called the BIT RATE is called BytesPerSec in PCM wave audio
code. 
samples per sec multiplied by block size.

>
>Now it is immediately clear why changing the sample rate will change 
>this number. Changing the sample rate does, however, NOT change the 
>word length of the individual samples because it's just a number 
>describing how many measurements are taken at each second, but not how 
>many amplitude levels they can distinguish (ie. how many bits each of 
>them contains).
>
>> So if you use samples per sec in non compression encoded files it
>> defines the two seperately.
>
>I'm sorry but I don't know what you're getting at. I never mentioned 
>compression and this has nothing to do with it - I was referring to raw 
>PCM data.
>

My point was, there is no need to express the rate as "bit per sec"
for a wave file, it doesnt mean anything in code for WAVE functions
and structures
"samples per sec" does.

"bit per sec" is only going to be of any value in code terms for
compression audio.


>>> The word length (for the "short int" data type this is usually 16 bits) 
>>> does not change with sample rate.
>> 
>> Yep, thats one channel maximum scale.
>> So
>> 16 bit audio is 4 byte per sample, 16 bit per channel stereo.
>
>One sample of a 16 bit audio recording is 2 bytes (= 16 bit) per 
>sample, with two samples per frame for stereo (left and right). This 
>equals 4 bytes in total.
>

Yeah I left out  "block" size
read "block" not "frame" in a PCM wave.

16 bits
4 bytes
When he adds up 16 bits over 4 bytes for stereo L and R Im sure he
will sort that one out in code.

Stereo
16 bit per sample in 4 bytes
or
16 bit per samples in 4 byte block size for stereo


>> giving scale range of 65534 per channel of which the centre point of
>> the scale at 32767 is 0 level sound.
>
>Nope. The correct number for the *range* is 65536 levels (0-65535) if 
>we're dealing with 16 bit unsigned data.
>
>> OR for working purposes
>> 16 bit using signed values -32767  max to +32767  max audio levels and
>> then 0 is 0 audio level.
>
>Nope, the minimum level for signed 16 bit data is -32768, not -32767.

-32768 might be the "minimum" level of a signed integer.
(do you mean, the minimum "value" for a signed integer ?)

Im refering to the number of audio "levels" each side of 0 to show
that 0 is the lowest audio level.
and the audio level increases with the value each side of 0 
32767 levels in the - direction for maximum audio level, and 32767 in
the plus direction for maximum audio level

But if it your wish it, make that.

The range is
0 -32768
and
0 +32768

On 2004-12-22 14:36:51 +0100, RV <do_not_use@email.com> said:

> On Wed, 22 Dec 2004 07:44:54 +0100, Stephan M. Bernsee
> <spam@dspdimension.com> wrote:
> 
>> I hope not!
>> 
>> Bit rate generally means the number of bits/sec.  Of course, for a 
>> change in sample rate this number changes, too.
> 
> Not quite, bit rate is the "rate" of bits over time.

That's what I said, is it not?

> "16 bit" or "8 bit" simply represents the block size in bits of each
> sample, it doesn't describe time.

Yes - again that's what I said.

> For bit per sec I suggest it's best to refer to wave as samples per
> sec.

Samples per sec doesn't say anything about the word length of the 
samples, this is something different. IOW: "samples per sec" does not 
define "bits per sec" without knowing the word length.

Again, to recap:

You store your data points (your SAMPLES) as numbers of a certain WORD 
LENGTH (typically 8, 16, 24, 32 BITS each) collected a certain SAMPLE 
RATE (typically specified as samples/sec). Also, you are usually 
dealing with FRAMES which contain a certain number of samples per 
channel. For a stereo recording, each frame contains 2 samples, left 
and right.

The BIT RATE would then be the total number of bits shuffled to the D/A 
converters (or any other device in the signal chain) in each second 
that passes. This rate would consequently be the product of the word 
length of the samples, the sample rate and the frame size (ie. number 
of channels) over one second.

Now it is immediately clear why changing the sample rate will change 
this number. Changing the sample rate does, however, NOT change the 
word length of the individual samples because it's just a number 
describing how many measurements are taken at each second, but not how 
many amplitude levels they can distinguish (ie. how many bits each of 
them contains).

> So if you use samples per sec in non compression encoded files it
> defines the two seperately.

I'm sorry but I don't know what you're getting at. I never mentioned 
compression and this has nothing to do with it - I was referring to raw 
PCM data.

>> The word length (for the "short int" data type this is usually 16 bits) 
>> does not change with sample rate.
> 
> Yep, thats one channel maximum scale.
> So
> 16 bit audio is 4 byte per sample, 16 bit per channel stereo.

One sample of a 16 bit audio recording is 2 bytes (= 16 bit) per 
sample, with two samples per frame for stereo (left and right). This 
equals 4 bytes in total.

> giving scale range of 65534 per channel of which the centre point of
> the scale at 32767 is 0 level sound.

Nope. The correct number for the *range* is 65536 levels (0-65535) if 
we're dealing with 16 bit unsigned data.

> OR for working purposes
> 16 bit using signed values -32767  max to +32767  max audio levels and
> then 0 is 0 audio level.

Nope, the minimum level for signed 16 bit data is -32768, not -32767.

> 8 bit audio is 2 byte per sample, 8 bit per channel.
> giving 256 scale range per channel of which the centre point of that
> scale at 128 is 0 level sound.
> 
> OR for working purposes
> 8 bit using signed values so  - 128 max to +128 max audio levels and
> then 0 is 0 audio level.

Nope again. It's -128 to +127 for 8 bit signed integers.

Hope this clears things up.
-- 
Stephan M. Bernsee
http://www.dspdimension.com

On Wed, 22 Dec 2004 07:44:54 +0100, Stephan M. Bernsee
<spam@dspdimension.com> wrote:

>On 2004-12-22 05:42:04 +0100, Jerry Avins <jya@ieee.org> said:
>
>> Emile wrote:
>> 
>>   ...
>> 
>>>> How? What does "bit rate" mean in this context, anyway?
>>>> 
>>> 
>>> i think it means how many bits are used to encode one sample in computer
>>> memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>>> that sample.
>> 
>> Most people I know would call that size, not rate. Is rate commonly used
>> that way among some groups?
>> 
>> Jerry
>
>I hope not!
>
>Bit rate generally means the number of bits/sec.  Of course, for a 
>change in sample rate this number changes, too.

Not quite, bit rate is the "rate" of bits over time.
"16 bit" or "8 bit" simply represents the block size in bits of each
sample, it doesn't describe time.

For bit per sec I suggest it's best to refer to wave as samples per
sec.

Not to be confused with compression encoded files where you would
count the bit rate of the encoded frames per sec to determine time,
not the just sample rate of the input samples per sec alone to
determine time as with a wave.

As in more or less compression = more or less bit rate, but at the
same sample rate from the input stream sample rate, the sample rate is
stored in the header of the frame in the case of mpeg audio.

So if you use samples per sec in non compression encoded files it
defines the two seperately.

>
>The word length (for the "short int" data type this is usually 16 bits) 
>does not change with sample rate.

Yep, thats one channel maximum scale.
So
16 bit audio is 4 byte per sample, 16 bit per channel stereo.
giving scale range of 65534 per channel of which the centre point of
the scale at 32767 is 0 level sound.

OR for working purposes
16 bit using signed values -32767  max to +32767  max audio levels and
then 0 is 0 audio level.

8 bit audio is 2 byte per sample, 8 bit per channel.
giving 256 scale range per channel of which the centre point of that
scale at 128 is 0 level sound.

OR for working purposes
8 bit using signed values so  - 128 max to +128 max audio levels and
then 0 is 0 audio level.

HTH
Cheers

On 2004-12-22 05:42:04 +0100, Jerry Avins <jya@ieee.org> said:

> Emile wrote:
> 
>   ...
> 
>>> How? What does "bit rate" mean in this context, anyway?
>>> 
>> 
>> i think it means how many bits are used to encode one sample in computer
>> memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>> that sample.
> 
> Most people I know would call that size, not rate. Is rate commonly used
> that way among some groups?
> 
> Jerry

I hope not!

Bit rate generally means the number of bits/sec.  Of course, for a 
change in sample rate this number changes, too.

The word length (for the "short int" data type this is usually 16 bits) 
does not change with sample rate.
-- 
Stephan M. Bernsee
http://www.dspdimension.com