Thread: [Audacity-devel] 2hr Recording Bug fix now in CVS
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
Menu
▾
▴
audacity-devel
|
From: James C. <cr...@in...> - 2004-07-28 13:04:07
|
I've tracked down a repeatable bug in recording on windows:
at 44100 Hz Mono takes 1hr 43 mins
at 96000 Hz Mono takes 48 mins
at 96000 Hz Stereo takes 23 mins.
for the record cursor to 'wrap around'.
in pa_win_mme.c
PaHost_UpdateStreamTime( PaWMMEStreamData *wmmeStreamData )
Was:
wmmeStreamData->framesPlayed += ((long)mmtime.u.sample) -
wmmeStreamData->lastPosition;
wmmeStreamData->lastPosition = (long)mmtime.u.sample;
Now:
wmmeStreamData->framesPlayed += (long)((DWORD)mmtime.u.sample -
(DWORD)(wmmeStreamData->lastPosition));
wmmeStreamData->lastPosition = (long)mmtime.u.sample;
I'm hoping this is the underlying cause of the recording bug that has been
reported to the list.
It would be a huge help if someone else with windows would try a 2hr
recording at 96000Hz Stereo before this patch, and then again after.
If they get the anticipated results, then I think we can safely close the
bug.
--James.
I also suspect this line
delta = info.bytes - pahsc->pahsc_LastPosPtr;
in the linux version of
Pa_UpdateStreamTime(PaHostSoundControl *pahsc)
Has the same problem,
pahsc_LastPosPtr is an int
if info.bytes is a DWORD (I can't tell from the code I have)
then we need to (DWORD) cast pahsc_LastPosPtr to get
the correct delta in spite of wrap around.
--James.
|
|
From: CN <mi...@sc...> - 2004-07-28 15:00:24
|
On Wed, 28 Jul 2004 14:07:02 +0100, James Crook wrote: >I've tracked down a repeatable bug in recording on windows: > >at 44100 Hz Mono takes 1hr 43 mins >at 96000 Hz Mono takes 48 mins >at 96000 Hz Stereo takes 23 mins. > >for the record cursor to 'wrap around'. > > >in pa_win_mme.c > >PaHost_UpdateStreamTime( PaWMMEStreamData *wmmeStreamData ) > >Was: > wmmeStreamData->framesPlayed += ((long)mmtime.u.sample) - >wmmeStreamData->lastPosition; > wmmeStreamData->lastPosition = (long)mmtime.u.sample; > >Now: > wmmeStreamData->framesPlayed += (long)((DWORD)mmtime.u.sample - >(DWORD)(wmmeStreamData->lastPosition)); > wmmeStreamData->lastPosition = (long)mmtime.u.sample; > >I'm hoping this is the underlying cause of the recording bug that has been >reported to the list. James, is DWORD the correct type for use across all platforms? Perhaps there is a wx type to use? I vaguely remember DWORD being win specific. BTW, when I was testing the long recording some time ago, I think I had seen the dependency of the sampling rate and stereo/mono too! Cordially, Chacko |
|
From: Matt B. <mbr...@cs...> - 2004-07-28 15:19:04
|
CN wrote: > James Crook wrote: > > wmmeStreamData->framesPlayed += (long)((DWORD)mmtime.u.sample - > > (DWORD)(wmmeStreamData->lastPosition)); > > James, is DWORD the correct type for use across all platforms? > Perhaps there is a wx type to use? I vaguely remember DWORD being win > specific. The above code is in the Windows-specific PortAudio code, and is handling values from Windows API calls. James Crook wrote: > > I also suspect this line > > delta = info.bytes - pahsc->pahsc_LastPosPtr; // [...] > > Has the same problem, > > pahsc_LastPosPtr is an int > > if info.bytes is a DWORD (I can't tell from the code I have) > > then we need to (DWORD) cast pahsc_LastPosPtr to get > > the correct delta in spite of wrap around. It looks like info.bytes is also an int. (From OSS "soundcard.h", count_info::bytes has type "int".) |
|
From: CN <mi...@sc...> - 2004-07-29 16:20:51
|
On Wed, 28 Jul 2004 14:07:02 +0100, James Crook wrote: >I've tracked down a repeatable bug in recording on windows: > >at 44100 Hz Mono takes 1hr 43 mins >at 96000 Hz Mono takes 48 mins >at 96000 Hz Stereo takes 23 mins. > >for the record cursor to 'wrap around'. > > >in pa_win_mme.c > >PaHost_UpdateStreamTime( PaWMMEStreamData *wmmeStreamData ) > >Was: > wmmeStreamData->framesPlayed += ((long)mmtime.u.sample) - >wmmeStreamData->lastPosition; > wmmeStreamData->lastPosition = (long)mmtime.u.sample; > >Now: > wmmeStreamData->framesPlayed += (long)((DWORD)mmtime.u.sample - >(DWORD)(wmmeStreamData->lastPosition)); > wmmeStreamData->lastPosition = (long)mmtime.u.sample; > >I'm hoping this is the underlying cause of the recording bug that has been >reported to the list. > > > >It would be a huge help if someone else with windows would try a 2hr >recording at 96000Hz Stereo before this patch, and then again after. >If they get the anticipated results, then I think we can safely close the >bug. > >--James. Before making the above suggested changes, with yesterday afternoon's HEAD build, I tried a recording at 44100 stereo. Well, this time it was still running ok after about 2:45 hours. [During this time, all other apps were closed, and I did not even try any user interaction with W2K at all.] So I did not even try to make the change. I saved this project, but it took close to an hour for the save to complete!! [300 Mhz processor, but a very fast disk, with 8MB cache]. I can zip (using InfoZip) a 4 GB (that is twice the data size) partition in much less time than that :) I can only speculate how the data might be maintained currently in the temporary area, and how it is in the final project area. If the individual files/segments have not been edited prior to a save, I would imagine we can speed up this save by orders of magnitude, with renaming of the files into the save area (assuming the temp area and final save area are on the same partition). Any comments? Cordially, Chacko |
|
From: <xip...@xi...> - 2004-07-29 19:11:39
|
> I can only speculate how the data might be maintained currently in > the temporary area, and how it is in the final project area. If the > individual files/segments have not been edited prior to a save, I > would imagine we can speed up this save by orders of magnitude, with > renaming of the files into the save area (assuming the temp area and > final save area are on the same partition). Any comments? It is already being renamed into the new area. OTOH, if your temp directory is on one volue and your save goes to a different volume, then you have to move all the data byte-by-byte. Rename is only efficient if it's a rename on the same physical partition. Monty |
|
From: James C. <cr...@in...> - 2004-07-29 19:46:35
|
> Before making the above suggested changes, with yesterday afternoon's HEAD build, I tried a recording at 44100 stereo. Well, this time it was still running ok after about 2:45 hours. [During this time, all other apps were closed, and I did not even try any user interaction with W2K at all.] So I did not even try to make the change. > > I saved this project, but it took close to an hour for the save to complete!! [300 Mhz processor, but a very fast disk, with 8MB cache]. I can zip (using InfoZip) a 4 GB (that is twice the data size) partition in much less time than that :) > > I can only speculate how the data might be maintained currently in the temporary area, and how it is in the final project area. If the individual files/segments have not been edited prior to a save, I would imagine we can speed up this save by orders of magnitude, with renaming of the files into the save area (assuming the temp area and final save area are on the same partition). Any comments? > > Cordially, Chacko Wow, that's way too much time to save. If you're interested in tracking down what's taking all that time, a rough and ready way to profile is just to interrupt the program, notice what routine it is in, resume where you left off, and repeat a few times. You might also try reducing the block size (in sequence.cpp I think) and see if it is related to the number of blocks rather than the total quantity of data. If you reduce the block size by a factor of 60 you might get a similar problem at 3 mins recording, which would be more managable to track down. Thanks for reporting this. --James. |
|
From: <xip...@xi...> - 2004-07-29 20:18:17
|
On Thu, Jul 29, 2004 at 08:50:19PM +0100, James Crook wrote: > > I saved this project, but it took close to an hour for the save to > complete!! [300 Mhz processor, but a very fast disk, with 8MB cache]. I can > zip (using InfoZip) a 4 GB (that is twice the data size) partition in much > less time than that :) (and yeah, an hour is far too long, even in the worst case. Even straight copies shouldn't take that long unless your disk is suddenly furiously remapping bad sectors or something...) Monty |
|
From: CN <mi...@sc...> - 2004-07-29 20:31:16
|
[Yesterday's HEAD build, running on W2k, 300Mhz process with 400M main memory, with super fast disk for this class of machines.] I noticed that Audacity runs at a higher priority by default (2 above normal). These days one is hardpressed to find many apps that run at higher priority, unless they came from devious places like MS :) While I was recording [44100, stereo], I had the taskmanger performance window running. I could hear a click in the audacity recording every time the taskmanager was updating its window -- I am sure task manager can snatch in quite high priorities :) Anyway, the interesting observation was when I moved the mouse over many of Audacity's own buttons and tools, I could hear a lot of louder clicking in the recording -- BTW, those clicks do get saved as part of the recording. I lowered A's priority to normal, and somewhat unexpectedly, the clicks from the taskmanager update was weaker!! It seems to me that currently Audacity has all the threads running at high priorities all the time, even many of window painting ones, and they are competing against own family :) In my experience, higher priorities are useful only if the duration of a process is very short, say, a fraction of a second. For hour-long processes, keeping high priority only alienates other processes, with almost no beneifts, IMO. Of course, some of you, who are running super computers may be wondering what I am drinking :) It is only green tea. Cordially, Chacko |
|
From: Dominic M. <do...@au...> - 2004-07-30 00:29:36
|
CN wrote: > [Yesterday's HEAD build, running on W2k, 300Mhz process with 400M main memory, with super fast disk for this class of machines.] > > I noticed that Audacity runs at a higher priority by default (2 above normal). These days one is hardpressed to find many apps that run at higher priority, unless they came from devious places like MS :) Audacity has multiple threads. Did you find all of Audacity's threads in the taskmanager? They may show up as several different instances of Audacity. The audio I/O thread runs at a higher priority, but the GUI and other threads run at normal priority. > While I was recording [44100, stereo], I had the taskmanger performance window running. I could hear a click in the audacity recording every time the taskmanager was updating its window -- I am sure task manager can snatch in quite high priorities :) Anyway, the interesting observation was when I moved the mouse over many of Audacity's own buttons and tools, I could hear a lot of louder clicking in the recording -- BTW, those clicks do get saved as part of the recording. This is not normal. I think you have a hardware problem with your soundcard. What happens when you record using some other audio program other than Audacity? I'll bet you hear the same clicks, though there may be subtle differences. - Dominic > I lowered A's priority to normal, and somewhat unexpectedly, the clicks from the taskmanager update was weaker!! > > It seems to me that currently Audacity has all the threads running at high priorities all the time, even many of window painting ones, and they are competing against own family :) In my experience, higher priorities are useful only if the duration of a process is very short, say, a fraction of a second. For hour-long processes, keeping high priority only alienates other processes, with almost no beneifts, IMO. > > Of course, some of you, who are running super computers may be wondering what I am drinking :) It is only green tea. > > Cordially, Chacko > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|
From: <xip...@xi...> - 2004-07-30 02:04:50
|
On Thu, Jul 29, 2004 at 05:29:28PM -0700, Dominic Mazzoni wrote: > This is not normal. I think you have a hardware problem with your > soundcard. > > What happens when you record using some other audio program other than > Audacity? I'll bet you hear the same clicks, though there may be subtle > differences. If this is a PCI bus machine with a PCI video card, you're likely falling victim to a chipset bug where the PCI latency timer is being ignored during write-combining and/or busmastering; this is one way video drivers will cheat to get better benchmarks (by locking out other devices on the PCI bus, they can increase their own performance by about 2-3%). There is no way around it AFAIK on Windows, on Linux you can disable the write-combining via /proc/mtrr as a test. Monty |
|
From: CN <mi...@sc...> - 2004-07-30 06:18:53
|
On Thu, 29 Jul 2004 22:13:38 -0400, Monty wrote: >On Thu, Jul 29, 2004 at 05:29:28PM -0700, Dominic Mazzoni wrote: >> This is not normal. I think you have a hardware problem with your >> soundcard. >> >> What happens when you record using some other audio program other than >> Audacity? I'll bet you hear the same clicks, though there may be subtle >> differences. > >If this is a PCI bus machine with a PCI video card, you're likely >falling victim to a chipset bug where the PCI latency timer is being >ignored during write-combining and/or busmastering; this is one way >video drivers will cheat to get better benchmarks (by locking out >other devices on the PCI bus, they can increase their own performance >by about 2-3%). There is no way around it AFAIK on Windows, on Linux >you can disable the write-combining via /proc/mtrr as a test. > >Monty Well, I do have a PCI bus with a PCI video card. But I have not experienced this interaction when using other recording programs, perhaps because those programs put such a low load on cpu ... My usage with other programs had been for a very simple purpose: for recording CDs and Vinyls to mp3. Cordially, Chacko |
|
From: <xip...@xi...> - 2004-07-30 19:55:50
|
On Thu, Jul 29, 2004 at 11:19:11PM -0700, CN wrote: > Well, I do have a PCI bus with a PCI video card. But I have not > experienced this interaction when using other recording programs, > perhaps because those programs put such a low load on cpu ... Load on CPU has nothing to do with it. If the CPU usage is 0% and the sound card's record buffer is full, but it can't do anything because the IDE controller or the video card has the PCI bus locked during a busmastered burst transfer, you lose samples, period. If PCI latency is the problem, the other programs may simply be using much bigger sampling fragment sizes. Second, Audacity does large screen refreshes, which other realtime apps don't. It could be the video straw breaking the camel's back. > My > usage with other programs had been for a very simple purpose: for > recording CDs and Vinyls to mp3. Ripping CDs doesn't use the sound card at all. They're read directly as data. With all the pops & clicks in vinyl, how would you even know? :-) (I, for one, am very happy CDs replaced vinyl ;-) Monty |
|
From: CN <mi...@sc...> - 2004-07-30 20:24:29
|
On Fri, 30 Jul 2004 16:05:17 -0400, Monty wrote: >On Thu, Jul 29, 2004 at 11:19:11PM -0700, CN wrote: > >> Well, I do have a PCI bus with a PCI video card. But I have not >> experienced this interaction when using other recording programs, >> perhaps because those programs put such a low load on cpu ... > >Load on CPU has nothing to do with it. If the CPU usage is 0% and the >sound card's record buffer is full, but it can't do anything because >the IDE controller or the video card has the PCI bus locked during a >busmastered burst transfer, you lose samples, period. > >If PCI latency is the problem, the other programs may simply be using >much bigger sampling fragment sizes. > >Second, Audacity does large screen refreshes, which other realtime >apps don't. It could be the video straw breaking the camel's back. It would be very useful for the low power CPU users, if we can provide any relief here. I did a small expt with turning all the timer based refresh in TrackPanel, when minimized. It did reduce the average and peak load on the cpu considerably, very useful for long background record sessions. I have not checked this code in, since I am not sure this might cause any problems anywhere. If I get the go ahead from the experts here, I shall check this in. This is only a couple of lines to be added in one place. I had added the code for optionally turning off the VU meters and reducing its paint frequency, for similar reasons. There may be other places also where we can turn off painting during idle. Any suggestions? Also, like the various options we currently have to display waveform, spectrum, .., it might be very useful to have a simple progress bar for each channel. I think this would be consistent with the overall GUI we have, and should be trivial for somebody who knows how to do GUI. >> My >> usage with other programs had been for a very simple purpose: for >> recording CDs and Vinyls to mp3. > >Ripping CDs doesn't use the sound card at all. They're read directly >as data. With all the pops & clicks in vinyl, how would you even >know? :-) Yes, I knew ripping CDs did not involve the s. card. Well, as for vinyls, that is a one time project to convert my collection. I am from the previous generation, I had a large collection of vinyls two decades before there was any personal computers :) I get rid of the noise fairly well with Aud, waiting for click and pop removal :) >(I, for one, am very happy CDs replaced vinyl ;-) Well, that is why I am putting everything onto DVDs. Cordially, Chacko |
|
From: CN <mi...@sc...> - 2004-07-30 06:28:41
|
On Thu, 29 Jul 2004 17:29:28 -0700, Dominic Mazzoni wrote: >Audacity has multiple threads. Did you find all of Audacity's threads in the taskmanager? They may >show up as several different instances of Audacity. The audio I/O thread runs at a higher priority, >but the GUI and other threads run at normal priority. Here I see only one instance of Audacity among the taskmanager processes. On startup, it has Normal priority. When I try to record, it jumps 2 to High. It stays at High even after the recording is stopped. If I manually reset it back to Normal, and then play, again it jumps to High. After playing is stopped, it remains at High. So for all practical purposes, the only Aud process I see is always running at High. Cordially, Chacko |
|
From: Matt B. <mbr...@cs...> - 2004-07-30 07:08:04
|
CN wrote: > I noticed that Audacity runs at a higher priority by default (2 above > normal). These days one is hardpressed to find many apps that run at > higher priority, unless they came from devious places like MS :) This was fixed on the 1.2 branch by a patch to PortAudio's pa_win_wmme.c. The change hasn't been checked in on HEAD yet. You can apply the patch with this command, and check it in if it works: cvs up -j1.8 -j1.8.4.1 lib-src/portaudio/pa_win_mme/pa_win_wmme.c |
|
From: CN <mi...@sc...> - 2004-07-31 16:33:05
|
On Fri, 30 Jul 2004 00:07:40 -0700 (PDT), Matt Brubeck wrote: >CN wrote: > >> I noticed that Audacity runs at a higher priority by default (2 above >> normal). These days one is hardpressed to find many apps that run at >> higher priority, unless they came from devious places like MS :) > >This was fixed on the 1.2 branch by a patch to PortAudio's pa_win_wmme.c. >The change hasn't been checked in on HEAD yet. You can apply the patch >with this command, and check it in if it works: > > cvs up -j1.8 -j1.8.4.1 lib-src/portaudio/pa_win_mme/pa_win_wmme.c Matt, the version of pa_win_wmme.c in HEAD was 1.9 (when downloaded two days ago). So I assume the change you refer to has already been applied in HEAD? Cordially, Chacko |
|
From: Matt B. <mbr...@cs...> - 2004-07-31 16:48:52
|
CN wrote: > >This was fixed on the 1.2 branch by a patch to PortAudio's > >pa_win_wmme.c. The change hasn't been checked in on HEAD yet. You > >can apply the patch with this command, and check it in if it works: > > > > cvs up -j1.8 -j1.8.4.1 lib-src/portaudio/pa_win_mme/pa_win_wmme.c > > Matt, the version of pa_win_wmme.c in HEAD was 1.9 (when downloaded > two days ago). So I assume the change you refer to has already been > applied in HEAD? No, it hasn't. Revision 1.8 was the branch point for that file. After the branch point, the HEAD revisions are numbered 1.9, 1.10, etc. while branch revisions are numbered 1.8.4.1, 1.8.4,2, ... |
|
From: CN <mi...@sc...> - 2004-07-31 17:08:00
|
On Sat, 31 Jul 2004 09:48:50 -0700 (PDT), Matt Brubeck wrote: >CN wrote: > >> >This was fixed on the 1.2 branch by a patch to PortAudio's >> >pa_win_wmme.c. The change hasn't been checked in on HEAD yet. You >> >can apply the patch with this command, and check it in if it works: >> > >> > cvs up -j1.8 -j1.8.4.1 lib-src/portaudio/pa_win_mme/pa_win_wmme.c >> >> Matt, the version of pa_win_wmme.c in HEAD was 1.9 (when downloaded >> two days ago). So I assume the change you refer to has already been >> applied in HEAD? > >No, it hasn't. Revision 1.8 was the branch point for that file. After >the branch point, the HEAD revisions are numbered 1.9, 1.10, etc. while >branch revisions are numbered 1.8.4.1, 1.8.4,2, ... I just did a diff. The diff between 1.8 and 1.8.4.1 appears to be already in 1.9 (unless I am not doing this right). Cordially, Chacko |
|
From: Matt B. <mbr...@cs...> - 2004-07-31 17:28:27
|
CN wrote:
> On Sat, 31 Jul 2004 09:48:50 -0700 (PDT), Matt Brubeck wrote:
>
>>>> cvs up -j1.8 -j1.8.4.1 lib-src/portaudio/pa_win_mme/pa_win_wmme.c
>>>
>>> Matt, the version of pa_win_wmme.c in HEAD was 1.9 (when downloaded
>>> two days ago). So I assume the change you refer to has already been
>>> applied in HEAD?
>>
>> No, it hasn't. Revision 1.8 was the branch point for that file.
>
> I just did a diff. The diff between 1.8 and 1.8.4.1 appears to be
> already in 1.9 (unless I am not doing this right).
As far as I can tell, that patch has not been checked into HEAD as of 1.9.
This is from the diff between 1.8 and 1.8.4.1:
+
+#if 0 /* dmazzoni: this seems to cause problems */
if( !SetPriorityClass( GetCurrentProcess(), HIGH_PRIORITY_CLASS ) ) /* PLB20010816 */
{
result = paHostError;
sPaHostError = GetLastError();;
goto error;
}
+#endif
+
And this is the code in 1.9:
* Thanks to Alberto di Bene for spotting this.
*/
if( !SetPriorityClass( GetCurrentProcess(), HIGH_PRIORITY_CLASS ) ) /* PLB20010816 */
{
result = paHostError;
sPaHostError = GetLastError();;
goto error;
}
if( !SetThreadPriority( wmmeStreamData->engineThread, THREAD_PRIORITY_HIGHEST ) )
{
|
|
From: CN <mi...@sc...> - 2004-07-31 20:58:41
|
On Fri, 30 Jul 2004 00:07:40 -0700 (PDT), Matt Brubeck wrote: >CN wrote: > >> I noticed that Audacity runs at a higher priority by default (2 above >> normal). These days one is hardpressed to find many apps that run at >> higher priority, unless they came from devious places like MS :) > >This was fixed on the 1.2 branch by a patch to PortAudio's pa_win_wmme.c. >The change hasn't been checked in on HEAD yet. You can apply the patch >with this command, and check it in if it works: > > cvs up -j1.8 -j1.8.4.1 lib-src/portaudio/pa_win_mme/pa_win_wmme.c Matt, yes, with this fix, Aud behaves much better here (relative to other running programs). I have checked it in to HEAD. Cordially, Chacko |
|
From: Monty <xip...@xi...> - 2004-07-29 19:28:30
|
> It is already being renamed into the new area. OTOH, if your temp > directory is on one volue and your save goes to a different volume, > then you have to move all the data byte-by-byte. Rename is only > efficient if it's a rename on the same physical partition. Actually, it just occurred to me that the Undo history might have the blockfiles locked in the temp project, making the save a blockfile copy and not rename.. Matt, Josh, do you know offhand if that's what it is? Monty |
|
From: Matt B. <mbr...@cs...> - 2004-07-29 19:55:03
|
Monty wrote: > > It is already being renamed into the new area. OTOH, if your temp > > directory is on one volue and your save goes to a different volume, > > then you have to move all the data byte-by-byte. Rename is only > > efficient if it's a rename on the same physical partition. > > Actually, it just occurred to me that the Undo history might have the > blockfiles locked in the temp project, making the save a blockfile > copy and not rename.. Matt, Josh, do you know offhand if that's what > it is? No, that shouldn't be the problem. Blockfiles should only be locked if they are referenced by a saved project file (except in one special case where they are locked temporarily during a Paste() between projects). Blockfiles will not be locked just because they are in the undo history. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X