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 protected]> 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 protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/arwyn%40phasic.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
