Re: Problem while converting back to PCM
From: Mujtaba (tomujtaba_at_hotmail.com)
Date: 04/27/04
- Next message: Mujtaba: "which wave format for data transmission over the internet"
- Previous message: Alexander Grigoriev: "Re: waveout queuing"
- Next in thread: aihaug: "Re: Problem while converting back to PCM"
- Reply: aihaug: "Re: Problem while converting back to PCM"
- Messages sorted by: [ date ] [ thread ]
Date: 27 Apr 2004 07:09:40 -0700
Thanx Sir
for your valuable suggestions
actually i am getting real time data in DirectSound buffers and usnig
it for conversion say "500 bytes" buffer. Could you plz comment
something about it regarding your previous reply to my question.
Second thing is after converting from PCM to GSM i check the value in
desBufLenUsed which is 330, now i will check it and will discuss with
you.
Thanx
"aihaug" <aihaug@att.net> wrote in message news:<nhY9c.33528$_U.1280@lakeread05>...
> GSM works on multiples of 320 samples, or 640 bytes for 16-bit PCM.
> This is to convert FROM PCM into GSM 06.10 format.
>
> Your call to acmStreamPrepareHeader() specifies the INPUT buffer size
> as such a multiple.
>
> After the call to acmStreamConvert() for PCM to GSM 06.10, the
> hdr.cbDstLengthUsed field of the header structure now contains the
> size of the GSM 06.10 frame. I don't recall what this size is, but it should
> not matter. Use this size as your INPUT size for the subsequent call
> to acmStreamPrepareHeader when you are trying to convert FROM GSM 06.10
> to PCM.
>
> regards,
>
> dan haug
>
> "Mujtaba" <tomujtaba@hotmail.com> wrote in message news:8f4f92aa.0403290610.527f50b7@posting.google.com...
> > "Alexander Grigoriev" <alegr@earthlink.net> wrote in message news:<#wji3BWEEHA.2908@TK2MSFTNGP09.phx.gbl>...
> > > _END flag is ised if you want to get all last decoded samples. For GSM
> > > stream it may not be necessary, though, you may not want those.
> > >
> > > _START flag tells the codec to start convertion from blank state. If GSM
> > > combines samples from two adjacent frames using some window, you may need
> > > that flag. I don't know how GSM works, though.
> > >
> > > "aihaug" <aihaug@att.net> wrote in message
> > > news:mnW7c.942$pM1.208@lakeread06...
> > > > I had originally coded my acm-based codec modules by following the
> examples
> > > > in MSDN, which pass "0" for the flags argument. Those examples must be
> > > > wrong too. That said, my ACM-based codec system has worked just fine
> > > > for the past two years with "0" as the flags argument. I agree, however,
> > > > upon
> > > > consulting the documentation on acmStreamConvert(), that I probably should
> > > > be passing ACM_STREAMCONVERTF_BLOCKALIGN, although since
> > > > I pass in exactly the correct frame sizes for each codec, it is an
> > > > unnecessary
> > > > flag. Since I do real-time streaming with these codecs, not processing a
> > > > file
> > > > of data, when the stream is terminated, I do not need to call _END to
> > > > retrieve
> > > > any final predictor outputs. I probably should be calling _START upon
> > > > detection of a dropped packet. I do believe that "0" is a legitimate
> > > > argument
> > > > to this call.
> > > >
> > > > None-the-less, this poster's code is quite wrong, as he wants to convert
> > > > from
> > > > PCM to GSM and back to PCM, and he is obviously passing in incorrect
> > > > frame sizes.
> > > >
> > > > regards,
> > > >
> > > > dan haug
> > > >
> > > > "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> > > > news:etZGPbJEEHA.1272@TK2MSFTNGP11.phx.gbl...
> > > > > You routinely should use whatever the documentation tells you.
> > > > >
> > > > > It's not an argument that it "usually works". If you want it to work
> with
> > > > > other codecs, not only those you've tested, you _must_ pass proper flags
> to
> > > > > acmStreamConvert.
> > > > >
> > > > > "aihaug" <aihaug@att.net> wrote in message
> > > > > news:I4N7c.672$pM1.424@lakeread06...
> > > > > > I'm not sure that is the problem. I routinely use "0" for
> > > > > > acmConvertStream().
> > > > > > Rather, if your posted code is correct, you are passing an incorrect
> buffer
> > > > > > size
> > > > > > back into the GSM -> PCM conversion.
> > > > > >
> > > > > > Look at the results of the first acmStreamConvert() call. The
> > > > > > cbDstLengthUsed
> > > > > > field tells you what the resulting output buffer size is. Whatever
> that
> > > > > > value is,
> > > > > > it should be your INPUT size to the decompress call, not 10240.
> > > > > > The decompression fails because this isn't a valid decompression frame
> size.
> > > > > >
> > > > > > dan haug
> > > > > >
> > > > > > "Chris P. [MVP]" <msdn@chrisnet.net> wrote in message
> > > > > > news:OTij27CEEHA.3080@TK2MSFTNGP10.phx.gbl...
> > > > > > > Mujtaba wrote:
> > > > > > > > hi we r working on internet telephony, where we have to to some
> data
> > > > > > > > format conversion from PCM to GSM and back. We r facing problem
> stated
> > > > > > > > below...
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > We are using same buffers for conversion that is first we convert
> from
> > > > > > > > PCM to GSM and then back to the PCM from the resultant GSM buffer.
> > > > > > > > First conversion (PCM to GSM ) woks fine, while coverting back the
> > > > > > > > same buffer to PCM it return error code 512
> > > > > > > >
> > > > > > > > mr2 = acmStreamConvert (acmstream, &acmstreamhdr, 0);
> > > > > > > > //--------------------------------------------------------
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Could any body plz guide us about this problem
> > > > > > >
> > > > > > >
> > > > > > > Reading the documentation usually helps.
> > > > > > >
> > > > > > > Flags are important.
> > > > > > > ACM_STREAMCONVERTF_START
> > > > > > > ACM_STREAMCONVERTF_END
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> > Thanx for your kind guidance
> >
> > Could you plz tell me that frame sizes i have used in the above code
> > are not correct. Our destination buffer length is also same as the
> > output buffer recieve while converting back to PCM.
> >
> > Looking for your kind response...
- Next message: Mujtaba: "which wave format for data transmission over the internet"
- Previous message: Alexander Grigoriev: "Re: waveout queuing"
- Next in thread: aihaug: "Re: Problem while converting back to PCM"
- Reply: aihaug: "Re: Problem while converting back to PCM"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
