Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: jack-audio-connection-kit - The Jack Audio Connection Kit https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183912 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] ------- Additional Comments From [EMAIL PROTECTED] 2006-05-09 16:37 EST ------- > For review purposes, IMO, I'd recommend sticking with officially released > sources. After initial import/build, upgrading to a cvs version could be a > possibility. Would that be before the package is actually released to the repository? If the answer is "yes" then please ignore the following..... === ignorable stuff begins === :-) This version will not work correctly as released on x2 processors. It'd be a pretty bad introduction to Jack for users that have machines with those processors (ie: the program appears to not work). Maybe "not work" is too strong? This is what happens: Jack will start and depending on the time that has passed since the machine was booted and the amount of time the individual processors have been in power save modes[*] tons of warning messages of the type "delay of 3856.000 usecs exceeds estimated spare time of 2653.000; restart ..." will be printed by jackd (and I mean a lot of them). This will not (in my experience) translate into audible xruns, but the messages will be printed and users will immediately assume the system is broken. Another alternative: this patch applies cleanly over the last "official" version, I was using it till I switched to the clockfix branch: http://lalists.stanford.edu/lad/2006/01/att-0167/jack-clock3.patch This problem (drifting TSC's) existed in the kernel itself, it is fixed in the current fedora kernels, I think > 2.6.14 is needed. Who knows, there may be an official release coming soon with this fixed and hopefully that will happen before the package is released. [*] Jackd internally used to use the processor's TSC for timing, on X2 processors the TSC's of the two cpus can and do drift apart over time. Jack will hit false timing errors as the timing reference is initially set on one processor and later checked for elapsed time on the other. Original post when I first reported the problem (at the time I thought it was related to Ingo's -rt patch): http://sourceforge.net/mailarchive/forum.php?thread_id=8085535&forum_id=3040 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedorafirstname.lastname@example.org http://www.redhat.com/mailman/listinfo/fedora-package-review