Re: Recognizing iSight as audio input device?
Re: Recognizing iSight as audio input device?
- Subject: Re: Recognizing iSight as audio input device?
- From: William Stewart <email@hidden>
- Date: Fri, 24 Feb 2006 19:47:41 -0800
Might be a good point to reiterate a general comment:
You also cannot rely on 512 always being either
(1) The default I/O size
(2) Even a valid I/O Size
For (1) - the HAL will deliberately chose a size that is different
for devices operating at a higher sample rate - so the HAL will set a
default I/O size of 1024 for devices at a sample rate of 96KHz -
basically, we're trying to represent about 11msecs of time.
Some devices will not let you set them to certain I/O sizes - this is
true generally in one of two conditions:
(A) The device is using a user-land I/O model and its underlying I/Os
have some restrictions on I/O size (the iSight is an example of this)
(B) Most IOAudio (ie. most) audio devices that appear through the HAL
can generally be set to any I/O size. The restrictions are placed on
the upper end of the spectrum - that is, as you try to go for larger
I/O sizes. There, based on the size of the buffers being used by the
driver, at some point you will reach a limit beyond which we cannot
go. This is different for different drivers/devices
Bill
On 24/02/2006, at 5:31 PM, Jeff Moore wrote:
516 is a pretty weird buffer size. The default is 512, so to get
516, somebody would have to be setting it on purpose. Given that
you can't change the buffer size of the iSight, why not just set
the output to 800?
At any rate, I'm still a bit puzzled as to why I don't get the same
results that you do. My iSight seems to work just fine with the
ComplexPlayThru sample code on my G4 PowerBook running 10.4.5.
Whereas, you have seen this on two different machines. The only
clear difference I see is that the machines you are using have two
CPUs and my PowerBook has just the one. Do you get the same results
if you disable one of the processors?
On Feb 24, 2006, at 5:13 PM, Stephen Shaw wrote:
Looking at the # of frames on the inputProc it looks like using
iSight
it is processing (and filling the ring buffer with) 800 frames
instead
of the usual 512
Meanwhile the output proc is only processing (and pulling from the
ring
buffer) 516 frames per call, so it looks like it gets so far behind,
that the input proc just keeps overwriting it and resetting the read
start time.
Using HALLab, it looks like the firewire iSight is 48khz, and the IO
buffer size is 800, and the IO Buffer Size Range is 800 - 800.
In HALLab, the built-in audio has a rate of 48khz, and the IO buffer
size is 512, and the IO Buffer Size Range is 15-6144
I'm not certain how to prevent this overwrite from occurring, even
if I
increase the buffer, it will eventually happen.
Thanks!
-Stephen
According to the code for AudioRingBuffer::CheckTimeBounds, it
returns
kAudioRingBufferError_WayAhead when the requested range isn't
currently
in >the ring buffer.
I'd imagine that this implies that the input device isn't filling
the
ring >buffer up for some reason.
--
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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