Re: iMic Pops and Clicks (and lost frames)
Re: iMic Pops and Clicks (and lost frames)
- Subject: Re: iMic Pops and Clicks (and lost frames)
- From: EJ Campbell <email@hidden>
- Date: Fri, 23 Aug 2002 17:22:07 -0700
>
I have prepared a part from my last recording where the clicks
>
and a very funny sound are heard so that we all know what we are
>
talking about ;-)
>
http://www.koloro.de/iMicClick.html
>
>
> IMHO, a more likely explanation is interrupt latency.
>
>
Yes, this was my first thought, too. And I changed the buffer
>
settings and upgraded to a new version of either the recording
>
software and the USB-audio driver -- but it seems (at best) be
>
the same maybe even worse ...
>
Thanks for providing the clip. Those are exactly the pops and clicks that
I've experienced on a Titanium G4 400 with the iMic on Mac OS X 10.1.5. For
the longest time I thought it was my bug, and tried *everything* I could
think of to get rid of the clicks, including architectural changes, to no
avail.
I too think it is an interrupt latency issue. I have software play-through
in my application, and have noticed that when I use the iMic as the sound
input device, the sound output channel will slowly catch up to the sound
input device, meaning that, eventually, the output channel has to play a
buffer of silence in order to allow the input device time to catch up. The
way I've implemented play-through is by taking the incoming sound and
putting each buffer of frames into a ring buffer. The sound output channel
takes the oldest buffer from the ring and plays it, or, if no buffer is
available, it plays silence.
When I calculate the difference between the oldest un-played buffer and
newest written buffer, I notice that most of the time the difference stays
consistent. But occasionally it decreases (and never increases). When the
difference decreases, it means that at that time, the proc reading from the
input device was not writing to the ring buffer at the same rate as the
output proc was reading from the buffer. This difference change usually
corresponds to when I hear the clicks and pops.
So, it seems as if Core Audio is somehow loosing samples from the iMic. My
application currently uses the Sound Manager API, but I've written a small
Core Audio sample program (based on PlayThru Test) that demonstrates the
problem as well (I'm not sure if it is as bad with Core Audio). If anyone is
interested in my sample program, I can send you the CW8 project.
For example, the last time I ran my Core Audio sample program, the
difference between the oldest buffer and the newest buffer began at 88
buffers (this large initial difference is on purpose), and stayed relatively
consistent for 26 minutes. This means that when my calculations began, the
output proc was 88 buffers behind the input proc. Then, all of a sudden, at
the 26 minute mark, over the course of a second, the difference was reduced
by 7 buffers. Since each buffer was 512 frames, it means that 3584 input
frames were somehow lost during this second. From that point on the
difference again stayed consistent, vacillating between 81 and 80 buffers.
Then at the 35 minute mark, the difference went down to 80 buffers and
remained that way for about 54 minutes when it momentarily ticked down to 79
buffers. From that point on, for the next 60 minutes, the buffer difference
remained at 80 buffers.
-EJ
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.