Apple

I should note that GarageBand is using 128 frames/buffer in my testing and I know of no way to change that.

When I encounter a glitch it is not uncommon for me to note that when I see the discontinuity in the ConvertInputSample() call, it appears that the call is late in coming. I can also see that at the time of this discontinuity, the realtime thread in the driver continued to execute every msec. So if there was a momentary scheduling issue, it only seemed to affect the CoreAudio thread pulling the audio data.

From: Ed Wynne [mailto:email@hidden]
Sent: Thursday, October 22, 2015 4:10 PM
To: Mike Horgan
Cc: email@hidden
Subject: Re: usb input audio glitching OSX 10.11.1

This could simply be a CPU latency issue. CoreAudio will drop buffers if it can’t keep up. Does the glitch go away if you try using bigger buffers? Apple uses 512 by default for most devices.

Which isn’t to say that using 128 frames/buffer @ 44.1kHz should be unrealistic in this day n age… but I’ve seen enough reports of problems from people trying to use 64 frames/buffer to be skeptical. It all depends on the hardware and software being used. Maybe the realtime thread scheduling got worse in 10.11?

-Ed

On Oct 22, 2015, at 3:50 PM, Mike Horgan <email@hidden> wrote:

I am trying to track down intermittent glitching in audio recorded from a USB 1.1 device in the following configuration:

- Mac mini (late 2014) running OSX 10.11.1 (15B42)

- Recording using GarageBand 10.1.0

The device is not audio class compliant and I am running the Line 6 audio kext driver. Note that this behavior is one of a number of issues which seemingly were introduced with OSX 10.11. With the initial 10.11 seeds the audio driver wouldn't even stream audio. I've been able to identify some issues and implement some workarounds and the evolution of OSX now through the 10.11.1 beta seeds has improved the performance.

The glitches that I'm seeing are intermittent and appear random. There doesn't appear to be any regular frequency to them. Instrumentation from the driver doesn't show any unusual behavior in the execution of usb frame lists, nor the processing of the audio to the input sample buffer. I've also have run the device behind a usb analyzer and captured the raw data and verified that the glitch is not in the audio from the device. What I do see appears to be a discontinuity in the sampleBuf parameter to the ConvertInputSamples() method on the driver audio engine object. There appears to be a one to one correspondence between the number of glitches in the captured audio and the number of discontinuities I see in the instrumentation data from the driver.

At the point of the discontinuity it appears (at least from the instrumentation data) that ConvertInputSamples() had not been called at the usual time. With the size of my sample buffer, it was getting called every 2-3 msec and pulling 128 samples of data from the buffer. At the discontinuity it would appear that 8 msec have gone by and the call seems to be skipping 124 samples in the buffer. This particular glitch was 00:03:20 into a recording.

I'm wondering whether anyone has any insight about what might or might not cause something like this. Under what circumstances would Core Audio decide to adjust point in the sample buffer where it is going to read audio from the driver? I've looked at the instrumentation associated with timestamps reported to Core Audio and I don't see any glaring issues. With the size of the buffer and the sample rate (44100) the timestamps appear ~300 msec apart.

_______________________________________________
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