View Full Version : ML Audio Parameters

07-22-2004, 04:08 PM
Dear Fabrice

I give the value of 4 for ML_AUDIO_FRAME_SIZE_INT32 and 8 for ML_AUDIO_PRECISION_INT32.here's my questions:
1)if we present the ML_CHANNELS_4 for ML_AUDIO_CHANNELS_INT32, is it true that in this example we have presented 8 bits for each 4 channes?
2)another question is about the ML_AUDIO_FORMAT_INT32. as i know, the unsigned integer values occupy more than 8 bits in memory. but we are using from ML_AUDIO_FORMAT_U8 that tells type of samples is unsigned integer and each of them occupies 8 bits. so what does happen in this situation?
3)is my interpreation true:in this example we have 4 bytes for each "audio frame" and 8 bits for each "audio sample"; thus we have 4 samples in each audio frame that are in this manner:1234 1234 1234 1234 and each 1234 occupies 8 bits.if it's not true please instruct me.
4)And finally about the compression: we have these types for compression:

but i have found no comment for them.can you suggest me about the reference that introduce these compressions?


[ July 23, 2004: Message edited by: ehsan2004 ]

[ July 23, 2004: Message edited by: ehsan2004 ]

07-24-2004, 07:44 AM
Hi Ehsan,

Note that you can't specify the value of ML_AUDIO_FRAME_SIZE_INT32 -- it is a "read-only" parameter. The device computes it based on other settings you make, and supplies the info to you for convenience. (See spec, page 70).

1) Yes, in this case you will receive 4 channels of 8 bits each, at the jack. Depending on ML_AUDIO_FORMAT, this may not be what you get in your buffer, however.

2) In this case, everything is fine -- you are specifying a precision of 8 bits at the jack, and requested unsigned 8-bit values in your buffer. No truncation, no padding. Note that these aren't "integers" (in the 32-bit traditional sense of the word) -- they are unsigned 8-bit values (ie: 'chars').

3) Your audio frame will be composed of 4 samples -- one each for chanels 1, 2, 3, 4. Each sample is 8 bits, ie: 1 byte. So your total frame size is 4 bytes. I think this is pretty much what you're saying, actually.

4) These are industry-standard compression types, and it is beyond the ML spec's scope to describe them. If you more details, I suggest you try a Web search.