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.