Request for review 7124225: [macosx] Input lines support only current sample rate (original) (raw)

Alex Menkov alexey.menkov at oracle.com
Thu Feb 2 05:15:28 PST 2012

Hi Alex,

Thank you for the review. I've fixed the issue you mentioned. This are minor changes so I'm going to send request to push the updated fix (http://cr.openjdk.java.net/~amenkov/7124225/webrev.01/) to 7u4 repo.

Some explanation about discontinuity handling. We handle only discontinuity occurs on pause/resume of recording (AudioOutputUnitStop/AudioOutputUnitStart in terms of CoreAudio) (we don't need to reset resampler if some frames were dropped for any case). HAL starts at zero timestamp (actually the 1st data we get has "near-zero" timestamp).

regards Alex

On 02/02/2012 10:15, Alex Strange wrote:

On Jan 31, 2012, at 5:03 AM, Alex Menkov <alexey.menkov at oracle.com_ _<mailto:alexey.menkov at oracle.com>> wrote:

Hi all,

Please review a fix for http://bugs.sun.com/viewbug.do?bugid=7124225 webrev: http://cr.openjdk.java.net/~amenkov/7124225/webrev.00/ Summary of the changes: implemented resampler for TargetDataLine using AudioToolbox/AudioConverter (used only if requested sample rate does not match current device sample rate). regards Alex Looks ok except for two minor issues: + if (ABS(sampleRate - hardwareSampleRate)> 1) { + device->resampler = new Resampler(); + You could use fabs() here and not have to define ABS(). + if (!isSource) { + // for target lines we should ensure that sampleRate == current device sample rate + // (othewise we get error -10863 (kAudioUnitErrCannotDoInCurrentContext in AUComponent.h) + // from AudioUnitRender(in InputCallback)) I think this comment is unnecessary now (there's also a spelling error). Did you see any timestamp discontinuities in the input? I can understand it skipping some times, but not sure what could make it go backwards.

More information about the macosx-port-dev mailing list