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 


           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 

Another alternative: this patch applies cleanly over the last "official"
version, I was using it till I switched to the clockfix branch:

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):

Configure bugmail:
------- 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

Reply via email to