Re: Another newbie question -- format of raw data
Re: Another newbie question -- format of raw data
- Subject: Re: Another newbie question -- format of raw data
- From: "tahome izwah" <email@hidden>
- Date: Mon, 31 Jul 2006 22:15:36 +0200
Hi Bill,
I'm not quite sure what your problem is exactly, but did you account
for little/big endian-ness on the PC? When you say you are
transferring the data to the PC how is that accomplished? Are you
storing the data in a sound file? If you do that then there is some
ambiguity when using 32bit values - some programs expect them to be
signed integers, others expect them to be IEEE754 floating point
numbers. A misunderstanding at this point can cause real nasty
distortion and static.
HTH,
--tahome
2006/7/31, Bill Cunning <email@hidden>:
Hi all,
I have been fighting this beast for a while now, and progress is being made
slowly but surely, but It seems I have hit a brick wall.
I can capture the audio data using the 'guts' more or less of complex play
through and another sample … and the raw audio from the mac à> to server à>
back to mac works fine. The issue seems to be when I try and send it to a PC
or run it through an ADPCM Codec that all heck breaks loose . mac ->
codec-enc ---- codec-dec – mac fails with loud screeching noises and sending
it off to a pc gives about the same results.
It appears I am getting 32bit audio data from the hardware (Bytes per frame
== 4) single channel and the raw data appears to be BigEndian (00 00 xx xx)
---
I found the flags to set 16bit capture but setunitproperties fails if I try
and change it -- that would be question one … is it possible to change the
#bytes in captured stream? If I configure from midi configuration utility it
seems to let me set it to 16 bit, but this seems to be ignored when I open
the device / audio unit
The other question is is this data stream really just LinearPCM or is there
some other kind of encoding going on. If it was just audio data, it would
seem I could do something like value/256 à out à value *256 and it would
work .. but this (test case that has no use) causes playback to fail. Is
there some other kind of information encoded in the bitstream that is
getting lost when I try and process it this way.
Thanks for your help
Bill
iLinc Communications
Bill Cunning
Senior Software Developer
email@hidden
www.ilinc.com
165 Jordan Road
Troy, NY 12180
877.960.1700, X454
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden