soundcard buffer format
CASTalk.com Forum Index CASTalk.com
Discussion of DSP, FPGA, storage and embedded system.
 
 FAQFAQ   MemberlistMemberlist     RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Google
 
Web castalk.com
soundcard buffer format
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> DSP
Author Message
Jonas Rundberg
Guest





Posted: Tue Dec 21, 2004 8:48 pm    Post subject: soundcard buffer format Reply with quote

Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?

I use a HP laptop and I can't find any information about the soundcard
on HP's homepage.

Thank you.
Back to top
RV
Guest





Posted: Tue Dec 21, 2004 9:31 pm    Post subject: Re: soundcard buffer format Reply with quote

On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
wrote:

Quote:
Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?


The sampling rates doesnt change the max scale - to +
The bit rate does.
8 bit, 16 bit
Back to top
Jerry Avins
Guest





Posted: Wed Dec 22, 2004 12:56 am    Post subject: Re: soundcard buffer format Reply with quote

RV wrote:

Quote:
On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
wrote:


Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?



The sampling rates doesnt change the max scale - to +

That's what I thought too.

Quote:
The bit rate does.

How? What does "bit rate" mean in this context, anyway?

Quote:
8 bit, 16 bit

??

Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Back to top
Emile
Guest





Posted: Wed Dec 22, 2004 6:56 am    Post subject: Re: soundcard buffer format Reply with quote

Jerry Avins wrote:
Quote:
RV wrote:


On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
wrote:



Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?



The sampling rates doesnt change the max scale - to +


That's what I thought too.


The bit rate does.


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.

Quote:

8 bit, 16 bit


??

Jerry
Back to top
Randy Yates
Guest





Posted: Wed Dec 22, 2004 7:14 am    Post subject: Re: soundcard buffer format Reply with quote

ridpiska@hotmail.com (Jonas Rundberg) writes:

Quote:
Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?

I use a HP laptop and I can't find any information about the soundcard
on HP's homepage.

See the WAVEOUTCAPS structure and the waveOutGetDevCaps() win32 API function
call.
--
% Randy Yates % "...the answer lies within your soul
%% Fuquay-Varina, NC % 'cause no one knows which side
%%% 919-577-9882 % the coin will fall."
%%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO
http://home.earthlink.net/~yatescr
Back to top
Jerry Avins
Guest





Posted: Wed Dec 22, 2004 8:03 am    Post subject: Re: soundcard buffer format Reply with quote

Emile wrote:

...

Quote:
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
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Back to top
RV
Guest





Posted: Wed Dec 22, 2004 8:03 am    Post subject: Re: soundcard buffer format Reply with quote

On Wed, 22 Dec 2004 01:56:30 GMT, Emile <bla.abla@telenet.be> wrote:

Quote:
Jerry Avins wrote:
RV wrote:


On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
wrote:



Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?



The sampling rates doesnt change the max scale - to +


That's what I thought too.


The bit rate does.


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.


Yup thats it
8 bit or 16 bit for each channel L and R per sample.

But not encoded, just recorded as a raw sample for this exercise.
(a typo?)
Back to top
Stephan M. Bernsee
Guest





Posted: Wed Dec 22, 2004 8:03 am    Post subject: Re: soundcard buffer format Reply with quote

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

Quote:
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
Back to top
Emile
Guest





Posted: Wed Dec 22, 2004 4:32 pm    Post subject: Re: soundcard buffer format Reply with quote

RV wrote:
Quote:
On Wed, 22 Dec 2004 01:56:30 GMT, Emile <bla.abla@telenet.be> wrote:


Jerry Avins wrote:

RV wrote:



On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
wrote:




Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?



The sampling rates doesnt change the max scale - to +


That's what I thought too.



The bit rate does.


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.



Yup thats it
8 bit or 16 bit for each channel L and R per sample.

But not encoded, just recorded as a raw sample for this exercise.
(a typo?)



I mean by encoded: in some way expressed as a binary digit (= code
representation of that value). The same way as the decimal 6 can be
encoded as 110 in binary, but it is encoded as 00110110 when following
the ascii convention.
Back to top
RV
Guest





Posted: Wed Dec 22, 2004 6:36 pm    Post subject: Re: soundcard buffer format Reply with quote

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

Quote:
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.

Quote:

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
Back to top
RV
Guest





Posted: Wed Dec 22, 2004 7:18 pm    Post subject: Re: soundcard buffer format Reply with quote

On Wed, 22 Dec 2004 11:32:14 GMT, Emile <bla.abla@telenet.be> wrote:

Quote:
RV wrote:
On Wed, 22 Dec 2004 01:56:30 GMT, Emile <bla.abla@telenet.be> wrote:


Jerry Avins wrote:

RV wrote:



On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
wrote:




Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?



The sampling rates doesnt change the max scale - to +


That's what I thought too.



The bit rate does.


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.



Yup thats it
8 bit or 16 bit for each channel L and R per sample.

But not encoded, just recorded as a raw sample for this exercise.
(a typo?)



I mean by encoded: in some way expressed as a binary digit (= code
representation of that value). The same way as the decimal 6 can be
encoded as 110 in binary, but it is encoded as 00110110 when following
the ascii convention.

I understand whats meant it just that encoding is encoding,
compression is compression, and neither occurs during recording from a
sound car AD(analogue to digital) "converter".

AD converters dont "compress" or "encode", they just "convert".

An encoder uses a table to describe the encoding used so it can decode
it.
audio data values from a sound card line or mic input don't need to be
decoded as the levels represent the same thing as voltage in.
volts = data value on a linear scale.

The values given from the .data structure, are levels that correspond
directly to the AD converter as an actual voltage value at the input.

Just pure scale conversion that occurs from volts to data level
X numer of times a second.

For line in, 1v pp "scaled" to the bit size you use.
16 bit is simply more voltage increments fom the same 1volt pp input
than 8bit.
in 8 bit, +128 or -128 is maximum voltage input at 1v pp line input.
in 16 bit -32767 or +32767 is the same maximum voltage at the 1v pp
line input

For a "real world" application
You can read the scale of the audio buffer data value for level and
divide that by 1v pp and you can see the voltage at the sound card
input in precise increments of that.

Encoding such as ASCII isnt linear in size of the binary values bit
for bit.
It uses a table of conversion to decode, the ASCII standard.
Without that you would not be able to encode or decode binary to
ASCII, but the computer has the stadard stuffed in there already to
use.

MPEG encodes and decodes to the standard tables, without the external
table of the standard to data would be un decodable.

No such thing applies ot the sound card.
(ignoring on board mpeg encoders etc that ae secondary to the AD raw
values)

Cheers
Back to top
Jerry Avins
Guest





Posted: Wed Dec 22, 2004 7:47 pm    Post subject: Re: soundcard buffer format Reply with quote

You know what you mean; I know what you mean. As explanation, I think
you put some of it poorly.

RV wrote:

Quote:
On Wed, 22 Dec 2004 11:32:14 GMT, Emile <bla.abla@telenet.be> wrote:

...


Quote:
I mean by encoded: in some way expressed as a binary digit (= code
representation of that value). The same way as the decimal 6 can be
encoded as 110 in binary, but it is encoded as 00110110 when following
the ascii convention.


I understand whats meant it just that encoding is encoding,
compression is compression, and neither occurs during recording from a
sound car AD(analogue to digital) "converter".

AD converters dont "compress" or "encode", they just "convert".

The conversion is from an analog voltage to a bit pattern that
represents it. The bit pattern is construed as a number encoded in some
way, usually two's complement, sometimes offset binary.

Quote:

An encoder uses a table to describe the encoding used so it can decode
it.
audio data values from a sound card line or mic input don't need to be
decoded as the levels represent the same thing as voltage in.
volts = data value on a linear scale.

The encoding for numbers of at least one class -- mostly two's
complement, nowadays -- is hard wired into the processor, so no table is
needed.

Quote:
The values given from the .data structure, are levels that correspond
directly to the AD converter as an actual voltage value at the input.

Just pure scale conversion that occurs from volts to data level
X numer of times a second.

For line in, 1v pp "scaled" to the bit size you use.
16 bit is simply more voltage increments fom the same 1volt pp input
than 8bit.
in 8 bit, +128 or -128 is maximum voltage input at 1v pp line input.
in 16 bit -32767 or +32767 is the same maximum voltage at the 1v pp
line input

For a "real world" application
You can read the scale of the audio buffer data value for level and
divide that by 1v pp and you can see the voltage at the sound card
input in precise increments of that.

Encoding such as ASCII isnt linear in size of the binary values bit
for bit.
It uses a table of conversion to decode, the ASCII standard.
Without that you would not be able to encode or decode binary to
ASCII, but the computer has the stadard stuffed in there already to
use.

Converting ASCII to signed binary is easily accomplished without a
table. Converting it to signed decimal is even easier.

Quote:
MPEG encodes and decodes to the standard tables, without the external
table of the standard to data would be un decodable.

MPEG compresses. Strictly, an MPEG file is decompressed, not decoded.
It's easy to confuse while trying to explain.

Quote:
No such thing applies ot the sound card.
(ignoring on board mpeg encoders etc that ae secondary to the AD raw
values)

Cheers

Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Back to top
Peter K.
Guest





Posted: Wed Dec 22, 2004 8:24 pm    Post subject: Re: soundcard buffer format Reply with quote

] MPEG compresses. Strictly, an MPEG file is decompressed, not decoded.
] It's easy to confuse while trying to explain.

I kinda agree with you, but "MPEG compressor" gets ~2,890 hits on
google, while "MPEG encoder" gets ~229,000.

"MPEG decompressor" -> 545
"MPEG decoder" -> 98,300
The googlization of the English language, anyone?

Ciao,

Peter K.
Back to top
Emile
Guest





Posted: Wed Dec 22, 2004 9:26 pm    Post subject: Re: soundcard buffer format Reply with quote

Quote:
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.



Yup thats it
8 bit or 16 bit for each channel L and R per sample.

But not encoded, just recorded as a raw sample for this exercise.
(a typo?)



I mean by encoded: in some way expressed as a binary digit (= code
representation of that value). The same way as the decimal 6 can be
encoded as 110 in binary, but it is encoded as 00110110 when following
the ascii convention.


I understand whats meant it just that encoding is encoding,
compression is compression, and neither occurs during recording from a
sound car AD(analogue to digital) "converter".

AD converters dont "compress" or "encode", they just "convert".

An encoder uses a table to describe the encoding used so it can decode
it.
audio data values from a sound card line or mic input don't need to be
decoded as the levels represent the same thing as voltage in.
volts = data value on a linear scale.

The values given from the .data structure, are levels that correspond
directly to the AD converter as an actual voltage value at the input.

Just pure scale conversion that occurs from volts to data level
X numer of times a second.

For line in, 1v pp "scaled" to the bit size you use.
16 bit is simply more voltage increments fom the same 1volt pp input
than 8bit.
in 8 bit, +128 or -128 is maximum voltage input at 1v pp line input.
in 16 bit -32767 or +32767 is the same maximum voltage at the 1v pp
line input

For a "real world" application
You can read the scale of the audio buffer data value for level and
divide that by 1v pp and you can see the voltage at the sound card
input in precise increments of that.

Encoding such as ASCII isnt linear in size of the binary values bit
for bit.
It uses a table of conversion to decode, the ASCII standard.
Without that you would not be able to encode or decode binary to
ASCII, but the computer has the stadard stuffed in there already to
use.

MPEG encodes and decodes to the standard tables, without the external
table of the standard to data would be un decodable.

No such thing applies ot the sound card.
(ignoring on board mpeg encoders etc that ae secondary to the AD raw
values)

Cheers

Interesting expanation, some things i didnt know, u clearly know more
about MPEG encoders and stuff than i do.
But the only thing i did was use the verb "to encode" in its literal
meaning: to express/convert something, an idea (in this case a value)
in/into code, nothing more, nothing less. This is also what i read in my
english dictionary (and now even several other english dictionaries to
be sure). I acknowledge that there may be some contexts in wich there is
a convention to use to encode in another meaning.

grtz
Emile
Back to top
glen herrmannsfeldt
Guest





Posted: Wed Dec 22, 2004 11:48 pm    Post subject: Re: soundcard buffer format Reply with quote

Emile wrote:

(someone wrote)

Quote:
When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?

(snip)

Quote:
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.

Bit rate should be bits/sample * sample rate * number of channels.

One can then trade off bits/sample and sample rate as appropriate.

That is before any compression. The term 'bit rate' may be more
applicable after compression where bits/sample isn't uniform anymore.

-- glen
Back to top
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> DSP All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




VoIP Electronics Powered by phpBB