Hi Jeff,
Thanks for your so quick
reply!
>> How are you looking at the data? Are you sure
it's not endian flipped?
I have set the
kIOAudioStreamByteOrderBingEndina while createing IOAudioStream, so I think the
data in mixbuf is BigEndian. Float32ToNativeInt32()
doesn’t do swap and I think the data after it should be BigEndian, too.
I just use %lx to print
them in FireLog and see the discrete values. In addition, sometimes positive
value will be followed with a negative value (e.g. 0x00000100, 0xFFFFFD00,
0x00000400), so it might not be of endian issue.
>> 200 * 4096 = 800k
>>That's might be a bit on the big side, but it
isn't an unreasonable amount of memory. I'd bet that depending on what kind of
memory your are allocating and what you are calling to do it, you >>
might be getting a failure. For example, if you needed all that memory to be
physically contiguous, you might see a failure as kernel memory gets more
fragmented.
>>
>> BTW, if you really do need to have that
memory be physically contiguous (and I don't think the FireWire controllers in
our machines do, but just in case), your best bet is to try to allocate the
>> memory as close to boot time as possible before kernel memory gets too
fragmented and your request is most likely to succeed.
Actually I need physically continuous
memory for DCL commands, which requires that. I think you’re right about the
time to allocate such a big memory. Because the success time is the first time
I load the driver. After use it to play or record, the second time allocation
will always fail. Does that means the 200 pages isn’t suitable for kernel case?
Sincerely yours,
David Tan
Dextrys Co., Ltd.