On Thu, 13 May 2004, Chris Cannam wrote: > I asked about this on the JACK list just now and was recommended to > bring the question here instead. So here we are. > > If I'm running JACK with output to my first (and only) PCM device, and > I have a JACK client running that also sets up an ALSA sequencer > queue with its timer set to the ALSA PCM 0-0-0 playback timer, > should I expect the ALSA queue's current time and the number of > frames processed by the JACK client to correspond? > > (Ignoring rounding error and any delays in startup time or > measurement: I simply mean that they shouldn't drift.) > > I would expect them to remain in sync, and on both of my machines here > they do, but I have a report from someone experiencing a quite > considerable drift -- the JACK frame count ends up over a second and > a half ahead of the ALSA timer over a ten minute period without > xruns. How could that happen?
Maybe, lost interrupts can cause this. Actually, there is no correction in the PCM slave timer code for this situation. Can this problem be reproduced using a bigger period size for the JACK daemon? Jaroslav ----- Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel