Forums

soundcard buffer format

Started by Jonas Rundberg December 21, 2004
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.
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 + The bit rate does. 8 bit, 16 bit
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?
> 8 bit, 16 bit
?? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
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.
> >>8 bit, 16 bit > > > ?? > > Jerry
ridpiska@hotmail.com (Jonas Rundberg) writes:

> 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
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 -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
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?)
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.
On Wed, 22 Dec 2004 11:32:14 GMT, Emile <bla.abla@telenet.be> wrote:

>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
You know what you mean; I know what you mean. As explanation, I think
you put some of it poorly.

RV wrote:

> On Wed, 22 Dec 2004 11:32:14 GMT, Emile <bla.abla@telenet.be> wrote: >
...
>>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.
> > 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.
> 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.
> 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.
> 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. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;