Re: [Audacity-devel] Latency correction
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Vaughan J. <va...@au...> - 2008-04-16 22:49:37
|
Finally had a chance to look at the latency correction issue. Quick recap is that we haven't been doing *any* automatic latency correction for a while (since 1.3.2, I think). Leland said the problem was that PortAudio v19 "simply doesn't provide usable or consistent values", so the code was commented out. It was: // As of 06/17/2006, portaudio v19 returns inputBufferAdcTime set to // zero. It is being worked on, but for now we just can't do much // but follow the leader. // // 08/27/2006: too inconsistent for now...just leave it a zero. // /* if (numCaptureChannels > 0 && numPlaybackChannels > 0 && timeInfo->inputBufferAdcTime > 0) gAudioIO->mLastRecordingOffset = timeInfo->inputBufferAdcTime - timeInfo->outputBufferDacTime; else { if (gAudioIO->mLastRecordingOffset == 0.0) { const PaStreamInfo* si = Pa_GetStreamInfo( gAudioIO->mPortStreamV19 ); gAudioIO->mLastRecordingOffset = -si->inputLatency; } } */ I did some experimenting, and for me, the si->inputLatency gave a useful result. On my machine, it returned ~140ms. I did the click-track test per http://sourceforge.net/mailarchive/message.php?msg_id=Pine.GSO.4.58.0407241803470.17390%40turing and it was still off by ~25ms, but that's far better than ~165ms. When I set the latency correction pref to -25ms, the result was beautiful. I'm wondering a bit why Matt's results were so much better, but guessing it's because he was on Linux with ALSA. Okay, so I'd check that in, but it looks to me like the logic above isn't quite correct. We want to set mLastRecordingOffset only when we're recording while playing, right? So I think it should be: if (numCaptureChannels > 0 && numPlaybackChannels > 0) { if (timeInfo->inputBufferAdcTime > 0) gAudioIO->mLastRecordingOffset = timeInfo->inputBufferAdcTime - timeInfo->outputBufferDacTime; else if (gAudioIO->mLastRecordingOffset == 0.0) { const PaStreamInfo* si = Pa_GetStreamInfo( gAudioIO->mPortStreamV19 ); gAudioIO->mLastRecordingOffset = -si->inputLatency; } } And, per the 06/17/2006 comment, inputBufferAdcTime always comes back as zero, so this will always use the "else if" clause, but if PortAudio fixes inputBufferAdcTime, our code will be ready for it. Anybody think this isn't a good commit? If I commit it, think I should add a comment in the prefs dialog that says what value it's using for auto-correction? Also, Matt's click-track test would be useful to users. Don't recall if I suggested it should go in the manual, but I think it should. Btw, in an earlier msg on this, I suggested that if Pa_GetStreamInfo(...)->inputLatency wasn't useful, we might try Pa_GetDeviceInfo(recDeviceNum)->defaultLowInputLatency as a reliable default. But for my system it reports that as 200ms, which would be an over-correction, so forget that idea! Thanks, Vaughan |