• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Recognizing iSight as audio input device?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recognizing iSight as audio input device?


  • Subject: Re: Recognizing iSight as audio input device?
  • From: Jeff Moore <email@hidden>
  • Date: Fri, 24 Feb 2006 17:31:03 -0800

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
  • Follow-Ups:
    • Re: Recognizing iSight as audio input device?
      • From: William Stewart <email@hidden>
References: 
 >RE: Recognizing iSight as audio input device? (From: "Stephen Shaw" <email@hidden>)

  • Prev by Date: RE: Recognizing iSight as audio input device?
  • Next by Date: Re: Recognizing iSight as audio input device?
  • Previous by thread: RE: Recognizing iSight as audio input device?
  • Next by thread: Re: Recognizing iSight as audio input device?
  • Index(es):
    • Date
    • Thread