> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio > Controller (rev 02) > > The driver is obviously snd_hda_intel.
Yes. This is a well behaved driver (even if some people don;t like the hw interface much :-) and I have examples of it here. >> The change to ALSA, BTW, was simply to move the latency calculation to >> where it actually reflected the buffer fill; the old code was always >> one fragment off because it calculated latency not accounting for the >> fragment it was about to write. Does the old code have proper sync >> for you if you set the fragment size to something large? > > Audio is not well synchronized. With a "Playback buffer size" of 16384 it is > awful, and much better with 4096, but not perfect. With your patch > and "Disable hardware synch" switched off, synchronization is very good, > regardless of the buffer size. But there is this jerky video that catches up > with the audio only after a few seconds. Hm, this does potentially sound like 'now that sync is working, it has broken something else'... What specific format is the input you're testing with? What is the relative power of the hardware and is it multicore? What kind of disk subsystem? In all versions of Cinelerra, I've seen very bad behavior on the beginning of playback depending on the input format and project specifics. For example, before I made the YUV4MPEG fixes, I would regularly have the beginning of playback place so much instantaneous load on the machine that it would render the UI fully unresponsive until it had finished building indexes and fill the cache (all the time juttering and stuttering as it tried to play back under the massive work-ahead). And upon every track transition, the same thing would happen again as it would OMG NEW TRACK! and hose the machine into the ground again filling caches. In short, Cinelerra has a 'stampede' problem, made much worse by the massive multithreading. I do not know if this is underlying your problem, but it might be (eg, it's trying to load an index on demand while playback proceeds). The working sync may simply be giving enough accurate timing information that it is suddenly trying to hold sync through the load spike where it wasn't before (causing it to shed lots of frames). I'm not at all convinced this is the case, I'm positing. Ah! I have an idea. I assume you have a camera that works well with Cinelerra.... can you take a video of the problem in progress and send it to me? :-) That will end alot of guessing and hard-to-describe nature of the behavior. > The playback cursor does jump around while the video lags behind. Forward and backwards or only forward? jumping backwards is very unusual unless the audio is also skipping. Monty _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
