Created attachment 451556 [details]
File: backtrace

Hi tim, for configuring Jack, did you follow the steps at 

/usr/share/doc/jack-audio-connection-kit-*/README.Fedora

Hi Orcan,

actually, no I didn't. I didn't know it was there. But I had a look and this document only seems to help when configuring jackd to use pulseaudio and I'm telling jackd to use alsa. The document also mentions alsa, but directs the reader to a website that no longer seems to exist. (I'd be happy to use pulseaudio though, but I suspect this might be a lot more work to set up. But if that would give better performance / lower latency, then maybe I should try it anyway)

Meanwhile, I have been able to get the system sort of working and haven't had a crash or freeze the past couple of days. I am having periodic noise though. After a few minutes a kind of mixture between analog and digital noise starts to swell (maybe I'm imagining it, but this period seems to shorten when jackd, or some component that is connected to the jack framework, has more to process). This noise is only audible when some audio is fed to the jackd input, though it doesn't seem to make a difference if this is a virtual or hardware input.
Then after a few seconds while the noise is swelling, the jackd log shows something like this (numbers are different each time) :
22:11:38.937 XRUN callback (1).
delay of 6474.000 usecs exceeds estimated spare time of 1130.000; restart ...
22:11:39.789 XRUN callback (1 skipped).

And it seems this 'restart' that the log shows then fixes the noise in the audio. Obviously, this noise is not acceptable to me, but maybe I need to configure some things differently (though I'm not sure what is relevant to list here). Also, I don't know if this noise is only in the hardware output (playback to the system output) or if it follows the entire signal path (and could thus mess up an audio recording).

When using ZynAddSubFX, I can hear some clicks and pops too, but that may be an issue with the synth, as the audio seems clean when I use the input from my Edirol UA-25EX (except for the static I mentioned earlier in this post).

The way I'm starting jackd now is thus (though, the input and output hardware addresses seem to change on system boot, restart and/or shutdown):

22:03:10.955 /usr/bin/jackd -P89 -p128 -dalsa -r96000 -p128 -n16 -D -Chw:2 -Phw:1 -Xseq
22:03:10.959 JACK was started with PID=2446.
jackd 0.118.0
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 96000
creating alsa driver ... hw:1|hw:2|128|16|96000|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 96000Hz, period = 128 frames (1.3 ms), buffer = 16 periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 16 periods for capture
ALSA: final selected sample format for playback: 32bit float little-endian
ALSA: use 16 periods for playback

Hi tim, 
The noise and cracks may be happening because you don't run jack in realtime mode.

In order to run jack in realtime mode, you need to add yourself to the jackuser group. This can be done via (as root)
   # usermod -a -G jackuser "<your username>"
where the "<your username>" is the username you want to run the jack with,
and then log out of your session and log back in (or just restart).

This is explained in the README.Fedora file, but it is kind of blended into the pulseaudio configuration guide. I admit that this file needs a hand*. 

Afterwards, you should be able to start jackd with a higher priority (which means lower -P value), e.g. -P20 instead of -P89

Let me know if this works for you.


*If you have time, you can just edit the "USING ALSA DIRECTLY" section and send us the file. I will make sure the next RPM build contains the correct instructions.

Hi Orcan,

Thanks for your quick response! I'm not sure I understand fully though. I'm using QjackCtl (so I don't know all the jackd command line options) but I've checked the 'Realtime' box in the setup dialog and I'm in both the audio and jackuser groups:

[tim@novastar ~]$ groups
tim audio jackuser

Also, I've set these values according to some examples I've encountered:

[tim@novastar ~]$ cat /etc/security/limits.d/99-jack.conf | grep rtprio
@audio - rtprio 100
@jackuser - rtprio 100
@pulse-rt - rtprio 80

But from your explanation, I understand that a lower P (for Priority I assume) value means a higher priority. Could it be that the rtprio uses this principle too, and that the 100 is therefore making it impossible to use realtime mode?

[tim@novastar ~]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16003
max locked memory       (kbytes, -l) 1048576
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 100
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

So I think that I am (or at least I've tried) running in realtime mode. Should it say in the log when realtime mode has succeeded perhaps? Because I don't see any errors or warnings about that, but perhaps I'm looking in the wrong place. :)

I've changed the -P value to 20 and this seems to help somewhat. And changing it to 10 seems even better. I've still got the more-or-less digital noise though. But it does seem to sound less 'aggressive' and to take longer for it to occur. The volume is lower and it's less irritating, but it's still quite clearly present.

I could try setting it to prio 1. But I'm not sure if it's wise to do that with a server that has proven to me to be able of crashes and freezes and producing heaps of messages. If anything goes wrong with it and it doesn't offend the kernel enough, I would like to be able to kill it manually without doing a hard reset, because I'm quite sure that will offend all processes in the system :)

(In reply to comment #5)
> 
> [tim@novastar ~]$ cat /etc/security/limits.d/99-jack.conf | grep rtprio
> @audio - rtprio 100
> @jackuser - rtprio 100
> @pulse-rt - rtprio 80
> 

Hmm, this is not the default file that comes with the jack RPM. Did you modify it by hand? The default file reads

# Default limits for users of jack-audio-connection-kit

@jackuser - rtprio 20
@jackuser - memlock 4194304

@pulse-rt - rtprio 20
@pulse-rt - nice -20


I don't think setting -P1 is a good idea as it might render your system unstable.

Did you try the rt (realtime) kernel from PlanetCCRMA? If you didn't do so, I recommend you to check out the PlanetCCRMA and subscribe to the mailing list. There are many pro audio Fedora users over there whom you may want to talk to. They even have a 3rd party repo with packages we don't have yet at Fedora, including jack2. (well, we will have jack2 officially in Fedora 14)

Fernando at PlanetCCRMA (who is also a former jack developer) might give you a better explanation than me to explain what these settings mean.

> But from your explanation, I understand that a lower P (for Priority I assume)
> value means a higher priority. Could it be that the rtprio uses this principle
> too, and that the 100 is therefore making it impossible to use realtime mode?
> 
> [tim@novastar ~]$ ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 16003
> max locked memory       (kbytes, -l) 1048576
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 100
> stack size              (kbytes, -s) 10240
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 1024
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
> 
> So I think that I am (or at least I've tried) running in realtime mode. 

No, see the "real-time priority (-r) 100" line?  That is because your priority is set to 100 in your /etc/security/limits.d/99-jack.conf. This is too high. Please revert to the default value I gave above and retry.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This was assigned to me accidentally.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.