recording with DirectSound?
Locked
 
Administrator
|
Has anybody built DirectSound support into Audacity? Does it not
supporting recording, as stated at http://www.staudio.de/kb/english/drivers/ ("DirectSound however has a huge limitation: it is not possible to record audio signals."), which we link to from the wiki? Microsoft says it supports recording and there are lots of links that have code samples, so I'm wondering about what staudio is claiming. Thanks, Vaughan ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
Quoting Vaughan Johnson <[hidden email]>:
> Has anybody built DirectSound support into Audacity? > I do. That's the interface my wife uses all the time...less latency...real or perceived. :-) Leland ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
Administrator
|
Leland wrote:
> Quoting Vaughan Johnson <[hidden email]>: > > >> Has anybody built DirectSound support into Audacity? >> >> > I do. That's the interface my wife uses all the time...less latency...real or > perceived. :-) > > Thanks, Leland. I guess that answers the question about recording, too -- so what was the staudio guy talking about ?! Should we continue to link to that page if it's misinformation? Since there are no licensing issues with DirectSound, shouldn't we build it into releases? - Vaughan ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
Quoting Vaughan Johnson <[hidden email]>:
> Leland wrote: > > Quoting Vaughan Johnson <[hidden email]>: > > > > > >> Has anybody built DirectSound support into Audacity? > >> > >> > > I do. That's the interface my wife uses all the time...less latency...real > or > > perceived. :-) > > > > > > Thanks, Leland. > > I guess that answers the question about recording, too -- so what was > the staudio guy talking about ?! Should we continue to link to that page > if it's misinformation? > in 2003 so I wouldn't be hopeful if we asked him to change it, but it might be interesting to ask him to explain it. Heck, for all I know, DirectSound might be using MME behind the scenes for recording. (That was a joke..;-) > Since there are no licensing issues with DirectSound, shouldn't we build > it into releases? > I don't see why not. I'd be interested in how the KS support in portaudio has progressed. I got that working way back too, but never sent in the patches. Leland ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
In reply to this post by Vaughan Johnson
Vaughan Johnson wrote:
> Leland wrote: >> Quoting Vaughan Johnson <[hidden email]>: >> >> >>> Has anybody built DirectSound support into Audacity? >>> >>> >> I do. That's the interface my wife uses all the time...less latency...real or >> perceived. :-) >> >> > > Thanks, Leland. > > I guess that answers the question about recording, too -- so what was > the staudio guy talking about ?! Should we continue to link to that page > if it's misinformation? > > Since there are no licensing issues with DirectSound, shouldn't we build > it into releases? > works fine. The WDMKS fella still seems to need work. I tested both of them with today's PortAudio snapshot for the heck of it. (Haven't moved my wife to 1.3.7 yet, but she's gonna get it whether she likes it or not. :-)) Leland ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|
Administrator
|
In reply to this post by Leland (Audacity Team)
| From Leland <[hidden email]> | Mon, 29 Dec 2008 17:58:04 -0600 | Subject: [Audacity-devel] recording with DirectSound? > Quoting Vaughan Johnson <[hidden email]>: > > > Leland wrote: > > > Quoting Vaughan Johnson <[hidden email]>: > > >> Has anybody built DirectSound support into Audacity? > > >> > > >> > > > I do. That's the interface my wife uses all the time...less latency...real > > or perceived. :-) > > > > > > > > > > Thanks, Leland. > > > > I guess that answers the question about recording, too -- so what was > > the staudio guy talking about ?! Should we continue to link to that page > > if it's misinformation? > > > There is a lot of good info there too though. I see the page was last updated > in 2003 so I wouldn't be hopeful if we asked him to change it, but it might be > interesting to ask him to explain it. Just in case, I have written to him, and asked him if he can update it. I also put a note on our Wiki page against the link to his article. I agree we should not drop the link. > > Since there are no licensing issues with DirectSound, shouldn't we build > > it into releases? > > > I don't see why not. I'd be interested in how the KS support in portaudio has > progressed. I got that working way back too, but never sent in the patches. When we last discussed this, I guess we were influenced by rumours that ASIO might relent on licensing? As nothing seems to be happening now on that front, maybe we should add support - if so, now or after 1.4? Gale ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
>> I don't see why not. I'd be interested in how the KS support in portaudio has
>> progressed. I got that working way back too, but never sent in the patches. > > When we last discussed this, I guess we were influenced by rumours that > ASIO might relent on licensing? As nothing seems to be happening now on > that front, maybe we should add support - if so, now or after 1.4? > Actually, the support has been there for quite some time. All you have to do is install the DirectX SDK, get out of Visual Studio, get back in (needs to pull in new environment variables), and rebuild Audacity. It will automatically be enabled. Leland ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
Administrator
|
Leland wrote:
>>> I don't see why not. I'd be interested in how the KS support in portaudio has >>> progressed. I got that working way back too, but never sent in the patches. >>> >> When we last discussed this, I guess we were influenced by rumours that >> ASIO might relent on licensing? As nothing seems to be happening now on >> that front, maybe we should add support - if so, now or after 1.4? >> >> > Actually, the support has been there for quite some time. All you have > to do is install the DirectX SDK, get out of Visual Studio, get back in > (needs to pull in new environment variables), and rebuild Audacity. It > will automatically be enabled. > > Right, so we'll build it into releases rather than have it an option. And it's a separate issue from ASIO -- there are lots of cards that have DirectSound drivers but not ASIO drivers. - Vaughan ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|
Administrator
|
| From Vaughan Johnson <[hidden email]> | Tue, 30 Dec 2008 11:40:51 -0800 | Subject: [Audacity-devel] recording with DirectSound? > Leland wrote: > >>> I don't see why not. I'd be interested in how the KS support in portaudio has > >>> progressed. I got that working way back too, but never sent in the patches. > >>> > >> When we last discussed this, I guess we were influenced by rumours that > >> ASIO might relent on licensing? As nothing seems to be happening now on > >> that front, maybe we should add support - if so, now or after 1.4? > >> > >> > > Actually, the support has been there for quite some time. All you have > > to do is install the DirectX SDK, get out of Visual Studio, get back in > > (needs to pull in new environment variables), and rebuild Audacity. It > > will automatically be enabled. > > Right, so we'll build it into releases rather than have it an option. > And it's a separate issue from ASIO -- there are lots of cards that have > DirectSound drivers but not ASIO drivers. Sure, but there are also generic ASIO drivers for WDM, like ASIO4ALL and ASIO2KS which are better than straight WDM. So in fact ASIO might have been a more universal solution. Gale ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
Administrator
|
In reply to this post by Leland (Audacity Team)
Leland wrote:
> ... > The WDMKS fella still seems to need work. I tested both of > them with today's PortAudio snapshot for the heck of it. > > Had some path/include issues in building with DirectX. Will update CVS. How far away is WDM-KS? Builds but crashes, or less terrible than that? - V ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
Vaughan Johnson wrote:
> Leland wrote: >> ... >> The WDMKS fella still seems to need work. I tested both of >> them with today's PortAudio snapshot for the heck of it. >> >> > Had some path/include issues in building with DirectX. Will update CVS. > > How far away is WDM-KS? Builds but crashes, or less terrible than that? > think it had something to do with buffering, but I don't recall for certain. Tracing found the problem for me though. Leland ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
Administrator
|
In reply to this post by Gale
Gale Andrews wrote: > | From Vaughan Johnson <[hidden email]> > | Tue, 30 Dec 2008 11:40:51 -0800 > | Subject: [Audacity-devel] recording with DirectSound? > >> Leland wrote: >> >>>>> I don't see why not. I'd be interested in how the KS support in portaudio has >>>>> progressed. I got that working way back too, but never sent in the patches. >>>>> >>>>> >>>> When we last discussed this, I guess we were influenced by rumours that >>>> ASIO might relent on licensing? As nothing seems to be happening now on >>>> that front, maybe we should add support - if so, now or after 1.4? >>>> >>>> >>>> >>> Actually, the support has been there for quite some time. All you have >>> to do is install the DirectX SDK, get out of Visual Studio, get back in >>> (needs to pull in new environment variables), and rebuild Audacity. It >>> will automatically be enabled. >>> >> Right, so we'll build it into releases rather than have it an option. >> And it's a separate issue from ASIO -- there are lots of cards that have >> DirectSound drivers but not ASIO drivers. >> > > Sure, but there are also generic ASIO drivers for WDM, like ASIO4ALL > and ASIO2KS which are better than straight WDM. So in fact ASIO > might have been a more universal solution. > > > meantime. - V ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
In reply to this post by Leland (Audacity Team)
On Tue, 2008-12-30 at 23:38 -0600, Leland wrote:
> Vaughan Johnson wrote: > > Leland wrote: > >> ... > >> The WDMKS fella still seems to need work. I tested both of > >> them with today's PortAudio snapshot for the heck of it. > >> > >> > > Had some path/include issues in building with DirectX. Will update CVS. > > > > How far away is WDM-KS? Builds but crashes, or less terrible than that? > > > Builds, but doesn't play. I ran into this problem last time too. I > think it had something to do with buffering, but I don't recall for > certain. Tracing found the problem for me though. Worth pointing out that both DirectSound and WDM-KS become emulated (and therefore largely pointless) on Vista, where the only native, low-latency API is WASAPI, which doesn't exist pre-Vista, and has only partial support in PortAudio. I have just updated the portaudio snapshot to the current portaudio SVN in order to pull in the minuscule changes since last March, but more importantly as a starting point to test a patch from their mailing list which is supposed to make audacity play better with pulseaudio on linux. Richard ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
Administrator
|
In reply to this post by Vaughan Johnson
I'm having problems with DirectSound support. Running on a Windows XP
laptop with SigmaTel sound chip. This is in HEAD, and the Jamling custom version based on 1.3.5. Problem occurs only when "Play other tracks while recording new one" is on. If I select a DirectSound driver for input and Sound Mapper or the Sigmatel WMME driver for output, it will record the first track fine, but on starting to record the second, gives "Error while opening sound device. Please check the input device settings and the project sample rate. If I have DirectSound drivers for both input and output, it records fine, then gives "Latency setting has caused the recorded audio to be hidden before zero..." I think very few people have built in DirectSound support, and Leland, you're the only one I actually know of. Have you seen this? Any ideas? Thanks, Vaughan ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
Vaughan Johnson wrote:
> I'm having problems with DirectSound support. Running on a Windows XP > laptop with SigmaTel sound chip. This is in HEAD, and the Jamling custom > version based on 1.3.5. > > Problem occurs only when "Play other tracks while recording new one" is > on. If I select a DirectSound driver for input and Sound Mapper or the > Sigmatel WMME driver for output, it will record the first track fine, > but on starting to record the second, gives "Error while opening sound > device. Please check the input device settings and the project sample rate. > > If I have DirectSound drivers for both input and output, it records > fine, then gives "Latency setting has caused the recorded audio to be > hidden before zero..." > > I think very few people have built in DirectSound support, and Leland, > you're the only one I actually know of. Have you seen this? > after she finished her Christmas CD. She's running an older version and the "Latency..." message wasn't in that version. Though, she would get it because that's what the latency correction does. I'm pretty sure she's going to ask me to remove it because she gets upwards of 15-20 tracks in a project and may do severals takes for a bit of singing. If she received that message everytime, she'd beat me silly. I don't see why we shouldn't be able to have one define MME and one DS. I'll take a quick peek as I'm looking through the code when researching the Vista problem. (But, feel free to look yourself if you like... ;-)) Leland ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
Leland wrote:
> Vaughan Johnson wrote: >> I'm having problems with DirectSound support. Running on a Windows XP >> laptop with SigmaTel sound chip. This is in HEAD, and the Jamling custom >> version based on 1.3.5. >> >> Problem occurs only when "Play other tracks while recording new one" is >> on. If I select a DirectSound driver for input and Sound Mapper or the >> Sigmatel WMME driver for output, it will record the first track fine, >> but on starting to record the second, gives "Error while opening sound >> device. Please check the input device settings and the project sample rate. >> >> If I have DirectSound drivers for both input and output, it records >> fine, then gives "Latency setting has caused the recorded audio to be >> hidden before zero..." I see what you mean. What's worse, is that it doesn't actually move the track data before 0 (at least not visually), so there's definitely some weirdness going on. Gotta get this fixed else my wife'll have my whatchamacallits for dinner. :-) Leland ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
In reply to this post by Vaughan Johnson
Vaughan Johnson wrote:
> > If I have DirectSound drivers for both input and output, it records > fine, then gives "Latency setting has caused the recorded audio to be > hidden before zero..." > Remember this bit in AudioIO()? // 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. // // 04/16/2008: Looks like si->inputLatency comes back with something useful though. // This rearranged logic uses si->inputLatency, but if PortAudio fixes inputBufferAdcTime, // this code won't have to be modified to use it. // Also avoids setting mLastRecordingOffset except when simultaneously playing and recording. // if (numCaptureChannels > 0 && numPlaybackChannels > 0) // simultaneously playing and recording { 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; } } Well, here's another case where the values can't be trusted. Search the portaudio-v19/hostapi directory for inputBufferAdcTime. You'll find that some APIs actually set it, but the WMME and DSOUND ones do not. They are marked as TODOs. You did notice some values there right? Those came from common/pa_process.c (near as I can tell) and only represent the amount of time the buffer processor takes. It probably wouldn't even be close to the real latency. And, you may notice that most of the time it comes back as zero. All of these values just are not consistently calculated by the different APIs. I added the following bit of code right after the last brace above and recorded twice on each platform. The first recording was into an empty project and the second one done soon after completing the first. The project rate was set at 44100 and number of channels was 2. Overdub was on See more comments below... { const PaStreamInfo* si = Pa_GetStreamInfo( gAudioIO->mPortStreamV19 ); wxLogDebug(wxT("iadc %f odac %f ilat %f olat %f inum %d onum %d offset %f\n"), timeInfo->inputBufferAdcTime, timeInfo->outputBufferDacTime, si->inputLatency, si->outputLatency, numCaptureChannels, numPlaybackChannels, gAudioIO->mLastRecordingOffset); } WMME API, 1st recording: 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 WMME API, 2nd recording: 00:26:35: Debug: iadc 0.000000 odac 5831.976663 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5831.975795 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5832.120745 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5832.116933 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5832.114587 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5832.142442 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5832.162983 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5832.197126 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5832.226185 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 00:26:35: Debug: iadc 0.000000 odac 5832.266317 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 NOTABLES: iadc is always zero. ilat looks like it might be valid. It would have to be tested to prove it out. DSOUND API, 1st recording: 00:28:37: Debug: iadc 0.000000 odac 5953.900221 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5953.923658 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5953.947073 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5953.970562 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5953.993897 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5954.021291 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5954.044735 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5954.068178 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5954.091576 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 00:28:37: Debug: iadc 0.000000 odac 5954.115227 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 DSOUND API, 2nd recording: 00:28:41: Debug: iadc 0.000000 odac 5958.628526 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 00:28:42: Debug: iadc 0.000000 odac 5958.662010 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 00:28:42: Debug: iadc 0.000000 odac 5958.682268 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 00:28:42: Debug: iadc 0.000000 odac 5958.699159 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 00:28:42: Debug: iadc 0.000000 odac 5958.742273 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 00:28:42: Debug: iadc 0.023220 odac 5958.765493 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 00:28:42: Debug: iadc 0.000000 odac 5958.745750 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 00:28:42: Debug: iadc 0.000000 odac 5958.783044 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 00:28:42: Debug: iadc 0.000000 odac 5958.806494 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 00:28:42: Debug: iadc 0.000000 odac 5958.819920 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 NOTABLES: iadc is ALMOST always zero...check what happens ot the offset when it isn't (this is cause the message dialog above) odac on first recording...why? ilat is always zero. olat on first recording...why? offset goes whacko if iadc isn't zero. COREAUDIO API, 1st recording: iadc 0.026644 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.074966 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.123288 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.171610 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.219955 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.280816 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.329161 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.377483 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.425805 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 0.474127 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 COREAUDIO API, 2nd recording: iadc 0.000000 odac 0.023220 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.046440 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.069660 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.092880 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.116100 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.139320 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.162540 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.185760 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.208980 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 iadc 0.000000 odac 0.232200 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 NOTABLES: iadc is zero when overdubbing ilat is always zero. ALSA API, 1st recording: iadc 745.844121 odac 0.000000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 745.881746 odac 0.025000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 745.919378 odac 0.050000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 745.957086 odac 0.075000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 745.994760 odac 0.100000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 746.032372 odac 0.125000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 746.068625 odac 0.150000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 746.107748 odac 0.175000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 746.145350 odac 0.200000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 iadc 746.182977 odac 0.225000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 ALSA API, 2nd recording: iadc 766.255139 odac 766.308473 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 766.378601 odac 766.431935 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 766.504767 odac 766.558101 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 766.629051 odac 766.682385 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 766.753588 odac 766.806922 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 766.877923 odac 766.931257 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 767.038065 odac 767.091399 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 767.170921 odac 767.224255 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 767.296019 odac 767.349353 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 iadc 767.421381 odac 767.474715 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 NOTABLES: odac on first recording...why...is suspect anyway. ilat on 1st recording is suspect. ilat during overdubbing may be correct, but it seems like it may be low...especially in my environment. (I wanted to try OSS, but couldn't get capture to work at all) As you can see, there's hardly any consistency in any of these values. If we still want to try and use them, we will have to code it up so it's API specific. Or simply not attempt to determine a latency and leave it up to the user to set in Preferences. I do realize an automatic latency determination would be best since various factors can affect the latency from recording to recording. But, can we trust what we're being given? Now, down to the problem this is causing when using the DirectSound API... The current determination of latency can't be used when the DirectSound API is active due to the iadc being non-zero every so often. If it was consistently zero, then it wouldn't be a problem. Leland ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
Administrator
|
Wow! Thanks, Leland. I thought that section was suspect, but didn't have
time to look into it before I had to leave last evening. Didn't mean for you to spend all that time tracking it down, but very grateful you did. I guess I'm leaning toward removing automatic latency correction again. Didn't know from the previous comments about its unreliability that it was SO flaky, and it's been working fine for my WMME driver -- just lucky I guess. Any other opinions about removing automatic latency correction? For Windows only? For WMME and DirectSound only? (Need to test with ASIO...) Thanks, Vaughan Leland wrote: > Vaughan Johnson wrote: > >> If I have DirectSound drivers for both input and output, it records >> fine, then gives "Latency setting has caused the recorded audio to be >> hidden before zero..." >> >> > Remember this bit in AudioIO()? > > // 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. > // > // 04/16/2008: Looks like si->inputLatency comes back with something useful though. > // This rearranged logic uses si->inputLatency, but if PortAudio fixes inputBufferAdcTime, > // this code won't have to be modified to use it. > // Also avoids setting mLastRecordingOffset except when simultaneously playing and recording. > // > if (numCaptureChannels > 0 && numPlaybackChannels > 0) // simultaneously playing and recording > { > 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; > } > } > > Well, here's another case where the values can't be trusted. Search the portaudio-v19/hostapi directory for inputBufferAdcTime. > You'll find that some APIs actually set it, but the WMME and DSOUND ones do not. They are marked as TODOs. You did notice some > values there right? Those came from common/pa_process.c (near as I can tell) and only represent the amount of time the buffer > processor takes. It probably wouldn't even be close to the real latency. And, you may notice that most of the time it comes back > as zero. > > All of these values just are not consistently calculated by the different APIs. > > I added the following bit of code right after the last brace above and recorded twice on each platform. The first recording was > into an empty project and the second one done soon after completing the first. The project rate was set at 44100 and number of > channels was 2. Overdub was on See more comments below... > > { > const PaStreamInfo* si = Pa_GetStreamInfo( gAudioIO->mPortStreamV19 ); > wxLogDebug(wxT("iadc %f odac %f ilat %f olat %f inum %d onum %d offset %f\n"), > timeInfo->inputBufferAdcTime, > timeInfo->outputBufferDacTime, > si->inputLatency, > si->outputLatency, > numCaptureChannels, > numPlaybackChannels, > gAudioIO->mLastRecordingOffset); > } > > > WMME API, 1st recording: > > 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 > > WMME API, 2nd recording: > > 00:26:35: Debug: iadc 0.000000 odac 5831.976663 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5831.975795 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5832.120745 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5832.116933 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5832.114587 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5832.142442 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5832.162983 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5832.197126 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5832.226185 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > 00:26:35: Debug: iadc 0.000000 odac 5832.266317 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 > > NOTABLES: > > iadc is always zero. > ilat looks like it might be valid. It would have to be tested to prove it out. > > DSOUND API, 1st recording: > > 00:28:37: Debug: iadc 0.000000 odac 5953.900221 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5953.923658 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5953.947073 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5953.970562 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5953.993897 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5954.021291 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5954.044735 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5954.068178 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5954.091576 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > 00:28:37: Debug: iadc 0.000000 odac 5954.115227 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 > > DSOUND API, 2nd recording: > > 00:28:41: Debug: iadc 0.000000 odac 5958.628526 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 > 00:28:42: Debug: iadc 0.000000 odac 5958.662010 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 > 00:28:42: Debug: iadc 0.000000 odac 5958.682268 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 > 00:28:42: Debug: iadc 0.000000 odac 5958.699159 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 > 00:28:42: Debug: iadc 0.000000 odac 5958.742273 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 > 00:28:42: Debug: iadc 0.023220 odac 5958.765493 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 > 00:28:42: Debug: iadc 0.000000 odac 5958.745750 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 > 00:28:42: Debug: iadc 0.000000 odac 5958.783044 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 > 00:28:42: Debug: iadc 0.000000 odac 5958.806494 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 > 00:28:42: Debug: iadc 0.000000 odac 5958.819920 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 > > NOTABLES: > > iadc is ALMOST always zero...check what happens ot the offset when it isn't (this is cause the message dialog above) > odac on first recording...why? > ilat is always zero. > olat on first recording...why? > offset goes whacko if iadc isn't zero. > > COREAUDIO API, 1st recording: > > iadc 0.026644 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.074966 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.123288 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.171610 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.219955 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.280816 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.329161 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.377483 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.425805 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 0.474127 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 > > COREAUDIO API, 2nd recording: > > iadc 0.000000 odac 0.023220 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.046440 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.069660 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.092880 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.116100 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.139320 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.162540 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.185760 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.208980 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > iadc 0.000000 odac 0.232200 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 > > NOTABLES: > > iadc is zero when overdubbing > ilat is always zero. > > ALSA API, 1st recording: > > iadc 745.844121 odac 0.000000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 745.881746 odac 0.025000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 745.919378 odac 0.050000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 745.957086 odac 0.075000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 745.994760 odac 0.100000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 746.032372 odac 0.125000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 746.068625 odac 0.150000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 746.107748 odac 0.175000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 746.145350 odac 0.200000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > iadc 746.182977 odac 0.225000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 > > ALSA API, 2nd recording: > > iadc 766.255139 odac 766.308473 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 766.378601 odac 766.431935 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 766.504767 odac 766.558101 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 766.629051 odac 766.682385 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 766.753588 odac 766.806922 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 766.877923 odac 766.931257 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 767.038065 odac 767.091399 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 767.170921 odac 767.224255 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 767.296019 odac 767.349353 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > iadc 767.421381 odac 767.474715 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 > > NOTABLES: > > odac on first recording...why...is suspect anyway. > ilat on 1st recording is suspect. > ilat during overdubbing may be correct, but it seems like it may be low...especially in my environment. > > (I wanted to try OSS, but couldn't get capture to work at all) > > As you can see, there's hardly any consistency in any of these values. If we still want to try and use them, we will have to code > it up so it's API specific. > > Or simply not attempt to determine a latency and leave it up to the user to set in Preferences. > > I do realize an automatic latency determination would be best since various factors can affect the latency from recording to > recording. But, can we trust what we're being given? > > Now, down to the problem this is causing when using the DirectSound API... > > The current determination of latency can't be used when the DirectSound API is active due to the iadc being non-zero every so often. > If it was consistently zero, then it wouldn't be a problem. > > Leland > > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: recording with DirectSound?
|
|
I tried Leland's test code, but only have MME and DirectSound here.
It looks to me like ilat and olat are the things to use to set mLastRecordingOffset, rather than iadc and oadc (??). Or maybe just olat would give more reliable results? Regrettable I have neither mike nor speakers to do any tests at the moment (the room I'm in is stripped bare, the chimney breast is in a state of rebuilding, there's a draught coming down it and it's rather chilly. And I had to get the computer out from under a dustsheet). If I had mike and speakers, I'd test latency like this (I've done it before and I think I did it like this): Generate silence for a few secs Zoom in at 1 sec so you can see the samples Drag one up to full amplitude to create a click (maybe the above replaced by 'generate a few 10's of ms of 1kHz sine') Put the mike as near as you can to the speaker. Turn gain up. Turn on Overdub and set Latency Correction to zero (Disable latency correction in the code, if you need to) Record the click Zoom in the the clicks and observe the latency Just for fun, put that value into Latency Correction, move the mike away by about a foot and try again, you should see an extra 1ms latency due to the speed of sound (about a foot a ms). Not as useful as it might have been, perhaps. A slightly dusty Martyn Vaughan Johnson wrote: > Wow! Thanks, Leland. I thought that section was suspect, but didn't have > time to look into it before I had to leave last evening. Didn't mean for > you to spend all that time tracking it down, but very grateful you did. > > I guess I'm leaning toward removing automatic latency correction again. > Didn't know from the previous comments about its unreliability that it > was SO flaky, and it's been working fine for my WMME driver -- just > lucky I guess. Any other opinions about removing automatic latency > correction? For Windows only? For WMME and DirectSound only? (Need to > test with ASIO...) > > Thanks, > Vaughan > > > Leland wrote: >> Vaughan Johnson wrote: >> >>> If I have DirectSound drivers for both input and output, it records >>> fine, then gives "Latency setting has caused the recorded audio to be >>> hidden before zero..." >>> >>> >> Remember this bit in AudioIO()? >> >> // 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. >> // >> // 04/16/2008: Looks like si->inputLatency comes back with something useful though. >> // This rearranged logic uses si->inputLatency, but if PortAudio fixes inputBufferAdcTime, >> // this code won't have to be modified to use it. >> // Also avoids setting mLastRecordingOffset except when simultaneously playing and recording. >> // >> if (numCaptureChannels > 0 && numPlaybackChannels > 0) // simultaneously playing and recording >> { >> 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; >> } >> } >> >> Well, here's another case where the values can't be trusted. Search the portaudio-v19/hostapi directory for inputBufferAdcTime. >> You'll find that some APIs actually set it, but the WMME and DSOUND ones do not. They are marked as TODOs. You did notice some >> values there right? Those came from common/pa_process.c (near as I can tell) and only represent the amount of time the buffer >> processor takes. It probably wouldn't even be close to the real latency. And, you may notice that most of the time it comes back >> as zero. >> >> All of these values just are not consistently calculated by the different APIs. >> >> I added the following bit of code right after the last brace above and recorded twice on each platform. The first recording was >> into an empty project and the second one done soon after completing the first. The project rate was set at 44100 and number of >> channels was 2. Overdub was on See more comments below... >> >> { >> const PaStreamInfo* si = Pa_GetStreamInfo( gAudioIO->mPortStreamV19 ); >> wxLogDebug(wxT("iadc %f odac %f ilat %f olat %f inum %d onum %d offset %f\n"), >> timeInfo->inputBufferAdcTime, >> timeInfo->outputBufferDacTime, >> si->inputLatency, >> si->outputLatency, >> numCaptureChannels, >> numPlaybackChannels, >> gAudioIO->mLastRecordingOffset); >> } >> >> >> WMME API, 1st recording: >> >> 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:31: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> 00:26:32: Debug: iadc 0.000000 odac 0.000000 ilat 0.116100 olat 0.000000 inum 2 onum 0 offset 0.000000 >> >> WMME API, 2nd recording: >> >> 00:26:35: Debug: iadc 0.000000 odac 5831.976663 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5831.975795 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5832.120745 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5832.116933 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5832.114587 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5832.142442 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5832.162983 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5832.197126 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5832.226185 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> 00:26:35: Debug: iadc 0.000000 odac 5832.266317 ilat 0.116100 olat 0.116100 inum 2 onum 2 offset -0.116100 >> >> NOTABLES: >> >> iadc is always zero. >> ilat looks like it might be valid. It would have to be tested to prove it out. >> >> DSOUND API, 1st recording: >> >> 00:28:37: Debug: iadc 0.000000 odac 5953.900221 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5953.923658 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5953.947073 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5953.970562 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5953.993897 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5954.021291 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5954.044735 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5954.068178 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5954.091576 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> 00:28:37: Debug: iadc 0.000000 odac 5954.115227 ilat 0.000000 olat 0.099977 inum 2 onum 0 offset 0.000000 >> >> DSOUND API, 2nd recording: >> >> 00:28:41: Debug: iadc 0.000000 odac 5958.628526 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 >> 00:28:42: Debug: iadc 0.000000 odac 5958.662010 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 >> 00:28:42: Debug: iadc 0.000000 odac 5958.682268 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 >> 00:28:42: Debug: iadc 0.000000 odac 5958.699159 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 >> 00:28:42: Debug: iadc 0.000000 odac 5958.742273 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -0.000000 >> 00:28:42: Debug: iadc 0.023220 odac 5958.765493 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 >> 00:28:42: Debug: iadc 0.000000 odac 5958.745750 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 >> 00:28:42: Debug: iadc 0.000000 odac 5958.783044 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 >> 00:28:42: Debug: iadc 0.000000 odac 5958.806494 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 >> 00:28:42: Debug: iadc 0.000000 odac 5958.819920 ilat 0.000000 olat 0.099977 inum 2 onum 2 offset -5958.742273 >> >> NOTABLES: >> >> iadc is ALMOST always zero...check what happens ot the offset when it isn't (this is cause the message dialog above) >> odac on first recording...why? >> ilat is always zero. >> olat on first recording...why? >> offset goes whacko if iadc isn't zero. >> >> COREAUDIO API, 1st recording: >> >> iadc 0.026644 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.074966 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.123288 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.171610 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.219955 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.280816 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.329161 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.377483 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.425805 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 0.474127 odac 0.000000 ilat 0.000000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> >> COREAUDIO API, 2nd recording: >> >> iadc 0.000000 odac 0.023220 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.046440 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.069660 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.092880 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.116100 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.139320 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.162540 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.185760 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.208980 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> iadc 0.000000 odac 0.232200 ilat 0.000000 olat 0.023220 inum 2 onum 2 offset -0.000000 >> >> NOTABLES: >> >> iadc is zero when overdubbing >> ilat is always zero. >> >> ALSA API, 1st recording: >> >> iadc 745.844121 odac 0.000000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 745.881746 odac 0.025000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 745.919378 odac 0.050000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 745.957086 odac 0.075000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 745.994760 odac 0.100000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 746.032372 odac 0.125000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 746.068625 odac 0.150000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 746.107748 odac 0.175000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 746.145350 odac 0.200000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> iadc 746.182977 odac 0.225000 ilat 0.100000 olat 0.000000 inum 2 onum 0 offset 0.000000 >> >> ALSA API, 2nd recording: >> >> iadc 766.255139 odac 766.308473 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 766.378601 odac 766.431935 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 766.504767 odac 766.558101 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 766.629051 odac 766.682385 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 766.753588 odac 766.806922 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 766.877923 odac 766.931257 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 767.038065 odac 767.091399 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 767.170921 odac 767.224255 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 767.296019 odac 767.349353 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> iadc 767.421381 odac 767.474715 ilat 0.085333 olat 0.085333 inum 2 onum 2 offset -0.053333 >> >> NOTABLES: >> >> odac on first recording...why...is suspect anyway. >> ilat on 1st recording is suspect. >> ilat during overdubbing may be correct, but it seems like it may be low...especially in my environment. >> >> (I wanted to try OSS, but couldn't get capture to work at all) >> >> As you can see, there's hardly any consistency in any of these values. If we still want to try and use them, we will have to code >> it up so it's API specific. >> >> Or simply not attempt to determine a latency and leave it up to the user to set in Preferences. >> >> I do realize an automatic latency determination would be best since various factors can affect the latency from recording to >> recording. But, can we trust what we're being given? >> >> Now, down to the problem this is causing when using the DirectSound API... >> >> The current determination of latency can't be used when the DirectSound API is active due to the iadc being non-zero every so often. >> If it was consistently zero, then it wouldn't be a problem. >> >> Leland >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> audacity-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
«
Return to audacity-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |