Re: Question about output data streaming
Re: Question about output data streaming
- Subject: Re: Question about output data streaming
- From: Jeff Moore <email@hidden>
- Date: Thu, 08 Jan 2009 12:37:47 -0800
On Jan 7, 2009, at 11:17 PM, David Tan wrote:
>> 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.
If you are on Intel hardware, then native endian is little endian.
Have you looked at the floating point values? It could be that
something is just getting munged in the conversion process.
>> 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?
It is always sketchy to allocate large buffers in the kernel after the
machine has been running a while.
At any rate, you might want to discuss this issue in more detail with
the FireWire folks. They'll be much better equipped to help you out
with your driver since the main issues seem to relate to just doing
FireWire stuff as opposed to doing audio stuff. They can also probably
help you out with the DCL program and optimizing it for Mac OS X and
the controllers we use.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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