Hi,
I am capturing 16 bit mono sound samples using some Win32 API function
calls. These function calls return the sound samples in an array of
characters. My assumption is that this array of characters represents pairs
of bytes that make up a short integer.
I'm using the following code to convert the samples:
LPTSTR *lpSaveBuffer;
......
for(j=0;j<nBytes;++J)
{
BYTE a = lpSaveBuffer[2*j]; // left byte
BYTE b = lpSaveBuffer[2*j + 1]; // right byte
short sample = (a << 8) | (b & 0xff);
}
I'm getting garbage as a result of this conversion. Any help would be
appreciated.
Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20060916/1ce9e9cd/attachment.htm
Is "nBytes" what it says -- the number of bytes in the buffer? If so,
you're overshooting the buffer by 2x by multiplying by 2 in your array
access. You probably want a variable called "nSamples" that
represents the
number of 16-bit words.
Also, if this is a little-endian (Windows on x86?) machine, you're
reassembling the word backwards.
Not to mention, shifting a BYTE left by 8 inside those parentheses is
probably turning it into 0. If you actually need to swap the bytes, try
casting to a short before shifting.
-- john
for(j=0;j<nBytes;++J)
{
BYTE a = lpSaveBuffer[2*j]; // left byte
BYTE b = lpSaveBuffer[2*j + 1]; // right byte
short sample = (a << 8) | (b & 0xff);
}
I'm getting garbage as a result of this conversion. Any help would be
appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20060916/62c5e7a8/attachment.html
Jonas Tärnström
2006-Sep-16 11:53 UTC
SV: [Speex-dev] converting 16-bit samples in LPSTR to short
What kind of crazy old Win32 API is that?
I?ve used DirectSound and WinMM and never needed to do something like
what you are doing.
AFAIK, all existing Win32 APIs for capturing sound returns buffers of
16-bit PCM data, assuming PCM was specified as buffer format.
//JT
-----Ursprungligt meddelande-----
Fr?n: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] F?r
Peter Gien
Skickat: den 16 september 2006 16:48
Till: speex-dev
?mne: [Speex-dev] converting 16-bit samples in LPSTR to short
Hi,
I am capturing 16 bit mono sound samples using some Win32 API function
calls. These function calls return the sound samples in an array of
characters. My assumption is that this array of characters represents
pairs of bytes that make up a short integer.
I'm using the following code to convert the samples:
LPTSTR *lpSaveBuffer;
......
for(j=0;j<nBytes;++J)
{
BYTE a = lpSaveBuffer[2*j]; // left byte
BYTE b = lpSaveBuffer[2*j + 1]; // right byte
short sample = (a << 8) | (b & 0xff);
}
I'm getting garbage as a result of this conversion. Any help would be
appreciated.
Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20060916/60786246/attachment.htm
Thank you John. I simply reversed the order of the bytes and that cleared up everything. But now that you mention it, it does look like I'm overshooting by a factor of two. I should rather do a loop that has j incrementing like this j+=2 and make the j loop run from 0 to nBytes/2. Thanks for the advice. On 9/16/06, John Miles <jmiles@pop.net> wrote:> > Is "nBytes" what it says -- the number of bytes in the buffer? If so, > you're overshooting the buffer by 2x by multiplying by 2 in your array > access. You probably want a variable called "nSamples" that represents the > number of 16-bit words. > > Also, if this is a little-endian (Windows on x86?) machine, you're > reassembling the word backwards. > > Not to mention, shifting a BYTE left by 8 inside those parentheses is > probably turning it into 0. If you actually need to swap the bytes, try > casting to a short before shifting. > > -- john > > for(j=0;j<nBytes;++J) > { > BYTE a = lpSaveBuffer[2*j]; // left byte > BYTE b = lpSaveBuffer[2*j + 1]; // right byte > short sample = (a << 8) | (b & 0xff); > } > > I'm getting garbage as a result of this conversion. Any help would be > appreciated. > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20060923/2159dd39/attachment.htm