Re: [Audacity-devel] sync problem solution
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Dominic M. <do...@mi...> - 2003-02-26 07:59:21
|
Joshua Haberman wrote: > I just came up with a solution that has solved the recording sync > problem completely for me, it's just a question of whether it's an > acceptable solution. > > It occurred to me that the problem is probably coming from concurrent > disk i/o on the block files that are being recorded: they are being > written from the audio thread and read from the GUI thread > simultaneously. My solution is this: don't draw a track as it is being > recorded. Once the recording is done, the whole track appears. > > If seeing a track as it is recording is important to us, an alternate > solution will probably entail adding a mechanism to BlockFile where a > block is marked "incomplete" upon creation, and marked "complete" when > it has been completely written. We would then disallow reads on > "incomplete" blocks. For a long time I've been planning to write a "Smart Record" dialog that lets you record without a complicated GUI. Our advice would be that "Smart Record" should be used for recording entire songs, long continuous recording, etc, while just clicking the big red button is good for short sound effects, mic tests, etc. In the meantime, I like your idea of marking BlockFiles as incomplete. Rather than putting the logic in BlockFile, though, I think that it can all be placed in WaveTrack. Notice what happens when AudioIO calls WaveTrack::Append: it buffers the samples, and only adds them to the Sequence when it has enough for a complete BlockFile. This would work great, except that there has to be a way to tell it that you're done appending for now, and that it should finish by adding an (incomplete) BlockFile to the end of the Sequence. Currently this is done on-demand - i.e. the audio data stays in the Append Buffer until someone comes along and queries some of the audio - then it flushes the Append Buffer. The problem is that the Append Buffer is being flushed by the UI thread while the Audio Thread is busy appending. So I think that we can solve this problem with just a small modification. Somehow we need to stop the UI drawing events from triggering a Flush. There are two possible approaches: 1. Tell the WaveTrack that it's in the middle of being recorded, and have it act differently in this case. When it's in "recording" mode, Append is the only method allowed to change any audio data - all other methods don't get to call Flush() 2. We could get rid of automatic calls to Flush(), and instead require that any function that calls Append MUST call Flush when it's finished appending. This is similar to how MP3 and Ogg encoding routines force you to tell it when you're done, otherwise the last few seconds won't ever be encoded. I think I prefer option #2: with Doxygen comments to make the WaveTrack interface crystal-clear, this would require the fewest code changes. Do you have time to fiddle with this? I'm still getting caught up... - Dominic > Josh > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |