6 Aug
2009
6 Aug
'09
10:44 a.m.
Simply listening to music with mplayer or xmms running through jack: I get
xruns approximately every 20 minutes--around the hour, 20min, 40min. Not exact
but +-2 second but around the third hour point.
Xmms running without the realtime option--this is an older application that
seems to want root priviliges to do this. Play is smooth except every 20
minutes.
Mplayer is fun -ao jack,alsa.
6 Aug
6 Aug
10:51 a.m.
David Baron wrote:
[ ... ]
Xmms running without the realtime option--this is an older application that
seems to want root priviliges to do this. Play is smooth except every 20
minutes.
Have you tried running with set_rlimits? Not all that difficult to set up and
works well for oddball situations.
cheers, Cal
11:45 a.m.
On Thursday 06 August 2009 15:51:39 cal wrote:
David Baron wrote:
How does this relate to pam's rlimits (these are set up rt, locked memory,
etc, for audio group)?
I have niced these processes negative. Did not help either (sound breakage
during other IO or Xorg activity) or the xruns. Xmms (the old one) scarcely
breaks at all at nice 0.
[ ... ]
Xmms running without the realtime option--this is an older application
that seems to want root priviliges to do this. Play is smooth except
every 20 minutes.
Have you tried running with set_rlimits? Not all that difficult to set up
and works well for oddball situations.
You might also check HAL polling with top or htop. I had a similar
problem on my notebook, QJackCtl reported xruns at regular intervals.
Htop revealed polling at exactly that interval. I disabled the polling,
the ticking went away.
There are non-user dbus and hald processes around. Needed for pulseaudio to
start (I do not use it) and for X to restart correctly, apparently.
How do I get rid of polling--where is all this configured?
9 Aug
9 Aug
9:28 a.m.
On Thu, Aug 6, 2009 at 9:45 AM, David Baron<d_baron(a)012.net.il> wrote:
I have niced these processes negative. Did not help
either (sound breakage
during other IO or Xorg activity) or the xruns. Xmms (the old one) scarcely
breaks at all at nice 0.
David - not picking on you in any way, just want to get the message
out there even more clearly: nice(1) has absolutely nothing useful to
offer any issues connected with scheduling processes to meet
hardware-determined deadlines (ie. your audio interface). People need
to get rid of this idea. Its not just "not the best way", its
completely irrelevant.
9:19 p.m.
On Sun, Aug 09, 2009 at 07:28:49AM -0400, Paul Davis wrote:
On Thu, Aug 6, 2009 at 9:45 AM, David
Baron<d_baron(a)012.net.il> wrote:
I'm nit picking ... I disagree with you here, Paul, but only in one
respect, when the system is CPU bound, that is there is no free CPU time
available.
nice(1) *does* have an effect on choosing which of several competing
user-space processes will execute next, and so will assist with
scheduling processes to meet hardware-determined deadlines (ie. incoming
audio samples from a mic).
But only if there are competing user-space processes.
If the processor is idle most of the time, which shows as a load
average less than 0.5, and is the usual situation these days, nice(1)
has no effect at all.
Putting it into human ... if the system is *only* doing your audio
recording job, then nice(1) will do nothing ... except make you feel
good.
Now, if your goal is only to feel good, and not to be right about it,
use it all you like, guys. ;-)
--
James Cameron
http://quozl.linux.org.au/
I have niced these processes negative. Did not
help either (sound breakage
during other IO or Xorg activity) or the xruns. Xmms (the old one) scarcely
breaks at all at nice 0.
David - not picking on you in any way, just want to get the message
out there even more clearly: nice(1) has absolutely nothing useful to
offer any issues connected with scheduling processes to meet
hardware-determined deadlines (ie. your audio interface). People need
to get rid of this idea. Its not just "not the best way", its
completely irrelevant. 
8 Aug
8 Aug
8:04 p.m.
cal wrote:
David Baron wrote:
> [ ... ]
>
> Xmms running without the realtime option--this is an older application that
> seems to want root priviliges to do this. Play is smooth except every 20
> minutes.
Maybe you have a regular chron job running every 20 minutes????
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
6 Aug
6 Aug
10:53 a.m.
Quoting David Baron <d_baron(a)012.net.il>il>:
Simply listening to music with mplayer or xmms running
through jack: I get
xruns approximately every 20 minutes--around the hour, 20min, 40min.
Not exact but +-2 second but around the third hour point.
Check your /etc/crontab and see if something there's the culprit. If
my suspicion is right you probably have an entry with 0,20,40 or */20
there.
11:08 a.m.
Peder Hedlund wrote:
Quoting David Baron <d_baron(a)012.net.il>il>:
You might also check HAL polling with top or htop. I had a similar
problem on my notebook, QJackCtl reported xruns at regular intervals.
Htop revealed polling at exactly that interval. I disabled the polling,
the ticking went away.
Best,
dp
Simply listening to music with mplayer or xmms
running through jack: I get
xruns approximately every 20 minutes--around the hour, 20min, 40min.
Not exact but +-2 second but around the third hour point.
Check your /etc/crontab and see if something there's the culprit. If
my suspicion is right you probably have an entry with 0,20,40 or */20
there.
6:05 p.m.
David Baron wrote:
Simply listening to music with mplayer or xmms running
through jack: I get
xruns approximately every 20 minutes--around the hour, 20min, 40min. Not exact
but +-2 second but around the third hour point.
Xmms running without the realtime option--this is an older application that
seems to want root priviliges to do this. Play is smooth except every 20
minutes.
Mplayer is fun -ao jack,alsa.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Actually, I get xruns with qjackctl every 14 minutes... Not really spent
any time tracking it down. Is there any software that will print current
running processes at the time of the xrun?
James
6:38 p.m.
On Thursday 06 August 2009 22:05:42 James Stone wrote:
Actually, I get xruns with qjackctl every 14
minutes...
That time is imho to long for the usual culprits like graphics or wireless.
Is your mail-app checking mails every 14 or 15 minutes? Is your instant
messenger rechecking its connection?
Maybe cron is the reason as todays systems configure it so that it runs every
quarter of an hour. I had that problem once (for me it was cron-triggered
backups during recording sessions) and "solved" it by editing the systems
crontab. It then only did the run-crons when "pidof jackd" didn't return a
pid
ie. if no jackd was running...
Arnold
10:11 p.m.
Arnold Krille wrote:
On Thursday 06 August 2009 22:05:42 James Stone
wrote:
Good ideas.. I tried to kill everything non-essential, but am still
getting an xrun every 14 minutes.. Here is the full top just 1 second
before the xrun occurred:
Tasks: 53 total, 1 running, 52 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 1036260k total, 675232k used, 361028k free, 46480k buffers
Swap: 1967920k total, 4k used, 1967916k free, 486244k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2276 root 15 -5 0 0 0 S 0.7 0.0 0:00.86 kjournald
9004 james 20 0 45760 44m 25m S 0.3 4.4 2:47.60 qjackctl
1 root 20 0 2168 728 628 S 0.0 0.1 0:01.48 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00
migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 0:00.18
ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root 15 -5 0 0 0 S 0.0 0.0 0:02.06 events/0
7 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
38 root 15 -5 0 0 0 S 0.0 0.0 0:00.18 kblockd/0
41 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
42 root 15 -5 0 0 0 S 0.0 0.0 0:00.00
kacpi_notify
140 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
175 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
176 root 20 0 0 0 0 S 0.0 0.0 0:00.84 pdflush
177 root 15 -5 0 0 0 S 0.0 0.0 0:00.24 kswapd0
178 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
720 root 15 -5 0 0 0 S 0.0 0.0 0:00.00
ksuspend_usbd
723 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khubd
747 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0
750 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata_aux
1155 root 15 -5 0 0 0 S 0.0 0.0 0:00.20 kjournald
1857 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kgameportd
2275 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2280 root 15 -5 0 0 0 S 0.0 0.0 0:00.92 kjournald
2281 root 15 -5 0 0 0 S 0.0 0.0 0:00.12 kjournald
2282 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2283 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2284 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2285 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2286 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2287 root 15 -5 0 0 0 S 0.0 0.0 0:00.26 kjournald
3269 root 20 0 1788 416 348 S 0.0 0.0 0:00.00 klogd
4290 root 20 0 15636 1812 1132 S 0.0 0.2 0:00.00 gdm
4293 root 20 0 16020 3152 2392 S 0.0 0.3 0:00.06 gdm
4323 root 20 0 62496 46m 7268 S 0.0 4.6 16:24.08 Xorg
4439 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4440 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4441 root 20 0 1784 528 460 S 0.0 0.1 0:00.00 getty
4442 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4443 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4444 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4468 james 20 0 7152 1160 932 S 0.0 0.1 0:00.04
WindowMaker
4605 james 20 0 9952 5520 3756 S 0.0 0.5 0:19.76
WindowMaker
8429 james 20 0 12952 3184 2484 S 0.0 0.3 0:00.46 aterm
8430 james 20 0 5300 1996 1344 S 0.0 0.2 0:00.00 bash
9010 james 20 0 22080 21m 4144 S 0.0 2.1 0:45.02 jackd
9642 james 20 0 13084 3300 2484 S 0.0 0.3 0:01.00 aterm
proc/interrupts:
CPU0
0: 229 XT-PIC-XT timer
1: 1349 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
4: 2 XT-PIC-XT ehci_hcd:usb3
5: 357787 XT-PIC-XT EMU10K1
6: 5 XT-PIC-XT floppy
7: 127 XT-PIC-XT NVidia nForce2
8: 4 XT-PIC-XT rtc
9: 0 XT-PIC-XT acpi
10: 131847 XT-PIC-XT ohci_hcd:usb1, nvidia
11: 239397 XT-PIC-XT ohci_hcd:usb2, eth0
12: 3 XT-PIC-XT bttv0
14: 23608 XT-PIC-XT ide0
15: 20132 XT-PIC-XT ide1
NMI: 0 Non-maskable interrupts
LOC: 402378 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
uname -a
Linux 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008 i686 GNU/Linux
So, you can see I am using a vanilla kernel, but the fact it's only
every 14 mins seems very strange to me. It is often preceded by a slow
build-up of static on audio output, which stops when the xrun happens
(this isn't recorded to disk in ardour tho).Any ideas what might be
going on? Could it be hardware-related??
James
Actually, I get xruns with qjackctl every 14
minutes...
That time is imho to long for the usual culprits like graphics or
wireless.
Is your mail-app checking mails every 14 or 15 minutes? Is your
instant messenger rechecking its connection?
Maybe cron is the reason as todays systems configure it so that it
runs every quarter of an hour. I had that problem once (for me it was
cron-triggered backups during recording sessions) and "solved" it by
editing the systems crontab. It then only did the run-crons when
"pidof jackd" didn't return a pid ie. if no jackd was running...
11:48 p.m.
On 08/07/2009 10:11 AM, James Stone wrote:
Linux 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008 i686 GNU/Linux
So, you can see I am using a vanilla kernel, but the fact it's only
every 14 mins seems very strange to me. It is often preceded by a slow
build-up of static on audio output, which stops when the xrun happens
(this isn't recorded to disk in ardour tho).Any ideas what might be
going on? Could it be hardware-related??
Do you have a wifi card?
They have been known to cause this kind of problem when they scan the
network.
Patrick Shirkey
Boost Hardware Ltd
James
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
7 Aug
7 Aug
12:03 a.m.
Patrick Shirkey wrote:
On 08/07/2009 10:11 AM, James Stone wrote:
No - nothing as flashy as that! I had that problem on my eeepc tho..
I have an old dial up modem card installed which I don't use any more
and a video capture card, which is likewise virtually never used. A
nvidia card, 3 HDs and a DVD RW... usb printer, kb, mouse and a graphic
tablet. That's pretty much it.
James
Linux 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008 i686 GNU/Linux
So, you can see I am using a vanilla kernel, but the fact it's only
every 14 mins seems very strange to me. It is often preceded by a slow
build-up of static on audio output, which stops when the xrun happens
(this isn't recorded to disk in ardour tho).Any ideas what might be
going on? Could it be hardware-related??
Do you have a wifi card?
They have been known to cause this kind of problem when they scan the
network.
12:04 a.m.
On Fri, Aug 07, 2009 at 01:11:01AM +0100, James Stone wrote:
Arnold Krille wrote:
Nope, it's because you're running a vanilla kernel :-)
Thread convergence here with the discussion of Kim's article and the advantages of
Linux over OSX or Windoze.
Sure, JACK will run on OSX and now even on Windoze. But Linux has a RT kernel available,
which will let you prioritize your audio apps so that this kind of glitch NEVER happens,
if you have it set up correctly. THAT is, IMHO, the "killer app" or key
difference between Linux and other platforms. And I hope those other platforms never get
it, because I am coloured by ideology :-)
Seriously, I think this is why Kim suggested that getting the RT kernel included in
distros (or in mainline kernel) is important: so that musicians can just choose it from
GRUB at boot time and be off and running with their favorite distro, in RT mode, without
any hassle, and with performance outstripping any competitor.
Several years ago, when I first got my laptop, on one occasion I was compiling Ardour2
(which as you may know, takes as long to build as a kernel) on a dual-core 64-bit Intel
running JACK while I had quite a few tracks going with lots of LASDPA plugins, ecasound,
jack-rack, Rosegarden, and a half-dozen softsynths... and not a single glitch. (It's
here, BTW: http://www.restivo.org/blog/archives/mmmm-carpets)
So, all politics aside, try it with an RT kernel, set your priorities correctly (RTC
highest, then your audio card IRQ, then jackd) and see what happens.
-ken
On Thursday 06 August 2009 22:05:42 James Stone
wrote:
Good ideas.. I tried to kill everything non-essential, but am still
getting an xrun every 14 minutes.. Here is the full top just 1 second
before the xrun occurred:
Tasks: 53 total, 1 running, 52 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 1036260k total, 675232k used, 361028k free, 46480k buffers
Swap: 1967920k total, 4k used, 1967916k free, 486244k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2276 root 15 -5 0 0 0 S 0.7 0.0 0:00.86 kjournald
9004 james 20 0 45760 44m 25m S 0.3 4.4 2:47.60 qjackctl
1 root 20 0 2168 728 628 S 0.0 0.1 0:01.48 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00
migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 0:00.18
ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root 15 -5 0 0 0 S 0.0 0.0 0:02.06 events/0
7 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
38 root 15 -5 0 0 0 S 0.0 0.0 0:00.18 kblockd/0
41 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
42 root 15 -5 0 0 0 S 0.0 0.0 0:00.00
kacpi_notify
140 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
175 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
176 root 20 0 0 0 0 S 0.0 0.0 0:00.84 pdflush
177 root 15 -5 0 0 0 S 0.0 0.0 0:00.24 kswapd0
178 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
720 root 15 -5 0 0 0 S 0.0 0.0 0:00.00
ksuspend_usbd
723 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khubd
747 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0
750 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata_aux
1155 root 15 -5 0 0 0 S 0.0 0.0 0:00.20 kjournald
1857 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kgameportd
2275 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2280 root 15 -5 0 0 0 S 0.0 0.0 0:00.92 kjournald
2281 root 15 -5 0 0 0 S 0.0 0.0 0:00.12 kjournald
2282 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2283 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2284 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2285 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2286 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
2287 root 15 -5 0 0 0 S 0.0 0.0 0:00.26 kjournald
3269 root 20 0 1788 416 348 S 0.0 0.0 0:00.00 klogd
4290 root 20 0 15636 1812 1132 S 0.0 0.2 0:00.00 gdm
4293 root 20 0 16020 3152 2392 S 0.0 0.3 0:00.06 gdm
4323 root 20 0 62496 46m 7268 S 0.0 4.6 16:24.08 Xorg
4439 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4440 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4441 root 20 0 1784 528 460 S 0.0 0.1 0:00.00 getty
4442 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4443 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4444 root 20 0 1784 524 460 S 0.0 0.1 0:00.00 getty
4468 james 20 0 7152 1160 932 S 0.0 0.1 0:00.04
WindowMaker
4605 james 20 0 9952 5520 3756 S 0.0 0.5 0:19.76
WindowMaker
8429 james 20 0 12952 3184 2484 S 0.0 0.3 0:00.46 aterm
8430 james 20 0 5300 1996 1344 S 0.0 0.2 0:00.00 bash
9010 james 20 0 22080 21m 4144 S 0.0 2.1 0:45.02 jackd
9642 james 20 0 13084 3300 2484 S 0.0 0.3 0:01.00 aterm
proc/interrupts:
CPU0
0: 229 XT-PIC-XT timer
1: 1349 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
4: 2 XT-PIC-XT ehci_hcd:usb3
5: 357787 XT-PIC-XT EMU10K1
6: 5 XT-PIC-XT floppy
7: 127 XT-PIC-XT NVidia nForce2
8: 4 XT-PIC-XT rtc
9: 0 XT-PIC-XT acpi
10: 131847 XT-PIC-XT ohci_hcd:usb1, nvidia
11: 239397 XT-PIC-XT ohci_hcd:usb2, eth0
12: 3 XT-PIC-XT bttv0
14: 23608 XT-PIC-XT ide0
15: 20132 XT-PIC-XT ide1
NMI: 0 Non-maskable interrupts
LOC: 402378 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
uname -a
Linux 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008 i686 GNU/Linux
So, you can see I am using a vanilla kernel, but the fact it's only
every 14 mins seems very strange to me. It is often preceded by a slow
build-up of static on audio output, which stops when the xrun happens
(this isn't recorded to disk in ardour tho).Any ideas what might be
going on? Could it be hardware-related??
Actually, I get xruns with qjackctl every 14
minutes...
That time is imho to long for the usual culprits like graphics or
wireless.
Is your mail-app checking mails every 14 or 15 minutes? Is your
instant messenger rechecking its connection?
Maybe cron is the reason as todays systems configure it so that it
runs every quarter of an hour. I had that problem once (for me it was
cron-triggered backups during recording sessions) and "solved" it by
editing the systems crontab. It then only did the run-crons when
"pidof jackd" didn't return a pid ie. if no jackd was running...
5:14 a.m.
Hi,
On Friday 07 August 2009 02:11:01 James Stone wrote:
It is often preceded by a slow
build-up of static on audio output, which stops when the xrun happens
(this isn't recorded to disk in ardour tho).
That is good (and new) information. This sounds more like some clock-skews
which run out of sync, then boom! a xrun and all is well again.
Any ideas what might be
going on? Could it be hardware-related??
Follow Ken's advice: Use an RT-patched kernel.
Have fun,
Arnold
6:09 a.m.
Arnold Krille wrote:
Hi,
On Friday 07 August 2009 02:11:01 James Stone wrote:
OK.. done that now.. also set IRQ sched prio for sound card to 99, jackd
prio to 89, run the pci latency fix..
uname -a
Linux 2.6.29 #1 SMP PREEMPT RT Fri Aug 7 02:24:17 BST 2009 i686 GNU/Linux
cat /proc/interrupts
CPU0
0: 119 XT-PIC-XT timer
1: 976 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
4: 4 XT-PIC-XT ehci_hcd:usb1
5: 866799 XT-PIC-XT EMU10K1
6: 5 XT-PIC-XT floppy
7: 1711 XT-PIC-XT NVidia nForce2
8: 0 XT-PIC-XT rtc0
9: 0 XT-PIC-XT acpi
10: 339411 XT-PIC-XT ohci_hcd:usb2, nvidia
11: 546369 XT-PIC-XT ohci_hcd:usb3, eth0
12: 3 XT-PIC-XT bttv0
14: 11794 XT-PIC-XT ide0
15: 47804 XT-PIC-XT ide1
NMI: 0 Non-maskable interrupts
LOC: 4999783 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance counter interrupts
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
ERR: 6
MIS: 0
~/jack_stuff$ ./irq_check 5
pid 2106's current scheduling policy: SCHED_FIFO
pid 2106's current scheduling priority: 99
#!/bin/sh
case $1 in
start)
# "open up" the PCI bus by allowing fairly long bursts for
all devices, increasing performance
setpci -v -s "*:*.*" latency_timer=b0
# maximise latency for SBLive!, thus allowing
# more data per PCI transfer and minimizing xfuns
setpci -v -s 01:0a.0 latency_timer=ff
esac
exit 0
But still get xruns every 14 mins!!!
08:34:43.555 JACK connection change.
08:34:43.563 JACK connection graph change.
08:49:02.342 XRUN callback (1).
**** alsa_pcm: xrun of at least 0.026 msecs
09:03:23.960 XRUN callback (2).
**** alsa_pcm: xrun of at least 0.026 msecs
James
It is often preceded by a slow
build-up of static on audio output, which stops when the xrun happens
(this isn't recorded to disk in ardour tho).
That is good (and new) information. This sounds more like some clock-skews
which run out of sync, then boom! a xrun and all is well again.
Any ideas what might be
going on? Could it be hardware-related??
Follow Ken's advice: Use an RT-patched kernel.
6:44 a.m.
On Fri, Aug 07, 2009 at 09:09:56AM +0100, James Stone wrote:
uname -a
Linux 2.6.29 #1 SMP PREEMPT RT Fri Aug 7 02:24:17 BST 2009 i686 GNU/Linux
cat /proc/interrupts
ERR: 6
That ERR is interesting. Does the xrun correspond to increments of ERR?
~/jack_stuff$ ./irq_check 5
pid 2106's current scheduling policy: SCHED_FIFO
pid 2106's current scheduling priority: 99
One of the things that increased priority on an IRQ doesn't do is
prevent other drivers from hogging the CPU during an interrupt. All
drivers that handle interrupts can be a cause, if they contain coding
flaws. If you can remove all drivers you don't need, reducing the
/proc/interrupts list of drivers to a bare minimum, you can effectively
exclude some of the problem space.
start)
# "open up" the PCI bus by allowing fairly long bursts for
all devices, increasing performance
setpci -v -s "*:*.*" latency_timer=b0
Does the problem happen without this line? I can imagine that a flawed
PCI transaction might take a lot longer than it should, and if you
increase the latency timer it may allow for more time not doing
anything.
But still get xruns every 14 mins!!!
Fascinating. This will make it easier to diagnose if it happens so
regularly. Things I think you should try:
1. be in a text console (chvt 1) at the time of one of the expected
events, and see if it still occurs ... this is so that you can exclude
interrupts from your graphics adaptor as being a contributor, since I
note that there are many interrupts counted on IRQ 10, which is shared
between USB and Nvidia.
2. disconnect all unnecessary USB devices, see if the problem goes
away, since I note that there are many USB interrupts counted on IRQ 10
and 11, ... you might even go so far as disconnecting a USB keyboard and
mouse for the time of one of the expected events.
3. look for cron events around that time, e.g. by reading the cron
configuration files, or brute force using "strace -o cron -p `pgrep
cron`", to see if the overrun is contributed to by scheduled activity.
--
James Cameron
http://quozl.linux.org.au/
8:50 a.m.
Thanks for the extra suggestions, but still no further:
James Cameron wrote:
Yes. This has no effect on the problem.
Yes - it still happens.
On Fri, Aug 07, 2009 at 09:09:56AM +0100, James Stone
wrote:
No, ERR stays constant at 6
uname -a
Linux 2.6.29 #1 SMP PREEMPT RT Fri Aug 7 02:24:17 BST 2009 i686 GNU/Linux
cat /proc/interrupts
ERR: 6
That ERR is interesting. Does the xrun correspond to increments of ERR? ~/jack_stuff$ ./irq_check 5
pid 2106's current scheduling policy: SCHED_FIFO
pid 2106's current scheduling priority: 99
One of the things that increased priority on an IRQ doesn't do is
prevent other drivers from hogging the CPU during an interrupt. All
drivers that handle interrupts can be a cause, if they contain coding
flaws. If you can remove all drivers you don't need, reducing the
/proc/interrupts list of drivers to a bare minimum, you can effectively
exclude some of the problem space.
start)
# "open up" the PCI bus by allowing fairly long bursts for
all devices, increasing performance
setpci -v -s "*:*.*" latency_timer=b0
Does the problem happen without this line? But still get
xruns every 14 mins!!!
Fascinating. This will make it easier to diagnose if it happens so
regularly. Things I think you should try:
1. be in a text console (chvt 1) at the time of one of the expected
events, and see if it still occurs ... this is so that you can exclude
interrupts from your graphics adaptor as being a contributor, since I
note that there are many interrupts counted on IRQ 10, which is shared
between USB and Nvidia.
2. disconnect all unnecessary USB devices, see if the problem goes
away, since I note that there are many USB interrupts counted on IRQ 10
and 11, ... you might even go so far as disconnecting a USB keyboard and
mouse for the time of one of the expected events.
All usb devices removed and xrun still occurs.
3. look for cron events around that time, e.g. by
reading the cron
configuration files, or brute force using "strace -o cron -p `pgrep
cron`", to see if the overrun is contributed to by scheduled activity.
I stopped cron, and it still happens.......
I'm wondering if it could be some problem with the sound card itself...
It is around 9 years old now! Will try with the on-board sound to see if
any improvement.
James
10:54 a.m.
In the end, I tracked down my 14 minute xruns to running the SBLive at
44100 instead of 48000.. I wonder if that would help with the OP problem?
Now, is this a bug with jack (v 0.116) or just a design problem with the
SBLive? I know the SBLive runs at 48000, and has to be resampled (or
something similar that I don't understand) to run at 44100, but surely
that shouldn't cause xruns.. The slow build of static before the xrun
now makes much more sense to me!
James
10:58 a.m.
Hi,
On Friday 07 August 2009 14:54:30 James Stone wrote:
In the end, I tracked down my 14 minute xruns to
running the SBLive at
44100 instead of 48000.. I wonder if that would help with the OP problem?
Now, is this a bug with jack (v 0.116) or just a design problem with the
SBLive? I know the SBLive runs at 48000, and has to be resampled (or
something similar that I don't understand) to run at 44100, but surely
that shouldn't cause xruns.. The slow build of static before the xrun
now makes much more sense to me!
I think this could be the problem also for the OP! Nowadays many sound devices
just work with fixed 48000kHz and resample when opened with other rates...
Arnold
8 Aug
8 Aug
12:16 a.m.
On Fri, Aug 07, 2009 at 02:57:56PM +0200, Arnold Krille wrote:
Hi,
On Friday 07 August 2009 14:54:30 James Stone wrote:
That makes sense to me. The question I have now is: who or what is doing the resampling?
Is it the card, internally? Or ALSA? If it's ALSA doing the resampling, then the
problem is likely the driver for the card.
Wherever it is, either ALSA driver or the card's firmware or hardware, it may be a
32-bit or 16-bit overflow. When audio cards are running in normal mode, they just sit
there most of the time unless you give them audio. But with JACK running, the card is
constantly being fed something (zeroes? I haven't looked to find out what exactly) all
the time. You'll notice your interrupt counter going up and up when JACK is running,
even if no sound is coming out, for instance.
So my guess is that, every 14 minutes, enough frames are pumped to the card for that
int/long/whatever to overflow. The strange sounds might be as it gets close to that
overflow point.
Total wild guess here, but that's where I'd think of looking.
-ken
In the end, I tracked down my 14 minute xruns to
running the SBLive at
44100 instead of 48000.. I wonder if that would help with the OP problem?
Now, is this a bug with jack (v 0.116) or just a design problem with the
SBLive? I know the SBLive runs at 48000, and has to be resampled (or
something similar that I don't understand) to run at 44100, but surely
that shouldn't cause xruns.. The slow build of static before the xrun
now makes much more sense to me!
I think this could be the problem also for the OP! Nowadays many sound devices
just work with fixed 48000kHz and resample when opened with other rates...
5:13 a.m.
On Saturday 08 August 2009 04:16:06 you wrote:
On Fri, Aug 07, 2009 at 02:57:56PM +0200, Arnold
Krille wrote:
Afaik its the cards doing the resampling.
That is why you should run jackd in 48kHz always, the resampling provided by
software especially on linux with libsamplerate is much better.
Have fun,
Arnold
On Friday 07 August 2009 14:54:30 James Stone
wrote:
That makes sense to me. The question I have now is: who or what is doing
the resampling? Is it the card, internally? Or ALSA? If it's ALSA doing the
resampling, then the problem is likely the driver for the card. In the end, I tracked down my 14 minute xruns to
running the SBLive at
44100 instead of 48000.. I wonder if that would help with the OP
problem? Now, is this a bug with jack (v 0.116) or just a design
problem with the SBLive? I know the SBLive runs at 48000, and has to be
resampled (or something similar that I don't understand) to run at
44100, but surely that shouldn't cause xruns.. The slow build of static
before the xrun now makes much more sense to me!
I think this could be the problem
also for the OP! Nowadays many sound
devices just work with fixed 48000kHz and resample when opened with other
rates...
9 Aug
9 Aug
9:36 a.m.
Ken - again, no picking on your personally, just want to clarify some
misconceptions for the record ...
On Fri, Aug 7, 2009 at 10:16 PM, Ken Restivo<ken(a)restivo.org> wrote:
That makes sense to me. The question I have now is:
who or what is doing the resampling? Is it the card, internally? Or ALSA? If it's ALSA
doing the resampling, then the problem is likely the driver for the card.
no ALSA driver that i am aware of does resampling. however, libasound,
the ALSA library used by all ALSA applications (including JACK when
run with the ALSA backend) can resample if you use a device name that
permits it. the most common device name for this is something like
"plughw:N", which will do resampling if the underlying hardware does
not support the sample rate you ask for. it is not particularly high
quality resampling. if you use the "hw:N" device name, as is
recommended for JACK, no resampling will ever occur in software.
Wherever it is, either ALSA driver or the card's
firmware or hardware, it may be a 32-bit or 16-bit overflow. When audio cards are running
in normal mode, they just sit there most of the time unless you give them audio. But with
JACK running, the card is constantly being fed something (zeroes? I haven't looked to
find out what exactly) all the time. You'll notice your interrupt counter going up and
up when JACK is running, even if no sound is coming out, for instance.
whenever you start an audio interface, it is running until you stop
it. perhaps you mean that other programs don't keep the interface open
when they are not playing audio. that would vary on a case by case
basis. ALSA also permits the app to leave the card running without the
app feeding anymore data - the app tells ALSA how to handle the
requirement to refill the card's data buffer - but i doubt if many
apps use this part of the ALSA API. in addition,
So my guess is that, every 14 minutes, enough frames
are pumped to the card for that int/long/whatever to overflow. The strange sounds might
be as it gets close to that overflow point.
nothing is going to overflow for hours. and when it does, nothing
happens. you're just going to have trust this hand-waving assertion,
and i'm willing to be proven wrong in the case of a particular
driver/hw combination.
--p
9:41 a.m.
Thanks Paul for your excellent and helpful input! Just one question:
On Sun, Aug 9, 2009 at 12:36 PM, Paul Davis<paul(a)linuxaudiosystems.com> wrote:
nothing is going to overflow for hours. and when it
does, nothing
happens. you're just going to have trust this hand-waving assertion,
and i'm willing to be proven wrong in the case of a particular
driver/hw combination.
So what do you think is the reason that we seem to get regular xruns
at fixed intervals 14-20 mins (depending on system) when a EMU10K1
card is run at 44100, whereas no xruns at 48000? (and also why I get a
build up of static sound in the last 5-10 seconds before the xrun)?
James
9:59 a.m.
On Sunday 09 August 2009 14:41:44 James Stone wrote:
All I got was a momentary break in the sound for the Xrun. No artifact before
or after. The periodicity, not precise buth there, remains.
Thanks Paul for your excellent and helpful input! Just
one question:
On Sun, Aug 9, 2009 at 12:36 PM, Paul Davis<paul(a)linuxaudiosystems.com>
wrote:
nothing is
going to overflow for hours. and when it does, nothing
happens. you're just going to have trust this hand-waving assertion,
and i'm willing to be proven wrong in the case of a particular
driver/hw combination.
So what do you think is the reason that we seem to get regular xruns
at fixed intervals 14-20 mins (depending on system) when a EMU10K1
card is run at 44100, whereas no xruns at 48000? (and also why I get a
build up of static sound in the last 5-10 seconds before the xrun)?
10:36 a.m.
On Sun, Aug 9, 2009 at 7:41 AM, James Stone<jamesmstone(a)gmail.com> wrote:
Thanks Paul for your excellent and helpful input! Just
one question:
On Sun, Aug 9, 2009 at 12:36 PM, Paul Davis<paul(a)linuxaudiosystems.com> wrote:
*if* the h/w can resample (and if any device could, this would be the
one i would guess it would be), its probably just a poor resampling
implementation, and possibly some interaction between that and the
driver. by "poor" i refer to code quality, not the resampling algo
itself. this card dates from roughly the switchover point when it
started to become "the rule" that cheap h/w ran at a single SR and its
driver resampled when necessary. they could just have done a poor
implementation before eventually making their newer cards rely on
driver resampling.
nothing is going to overflow for hours. and when
it does, nothing
happens. you're just going to have trust this hand-waving assertion,
and i'm willing to be proven wrong in the case of a particular
driver/hw combination.
So what do you think is the reason that we seem to get regular xruns
at fixed intervals 14-20 mins (depending on system) when a EMU10K1
card is run at 44100, whereas no xruns at 48000? (and also why I get a
build up of static sound in the last 5-10 seconds before the xrun)?
9:37 p.m.
On Sun, Aug 09, 2009 at 08:36:12AM -0400, Paul Davis wrote:
*if* the h/w can resample (and if any device could,
this would be the
one i would guess it would be), its probably just a poor resampling
implementation, and possibly some interaction between that and the
driver. by "poor" i refer to code quality, not the resampling algo
itself. this card dates from roughly the switchover point when it
started to become "the rule" that cheap h/w ran at a single SR and its
driver resampled when necessary. they could just have done a poor
implementation before eventually making their newer cards rely on
driver resampling.
I agree. This seems the most likely explanation.
I've had a look at sound/pci/emu10k1/emupcm.c in the kernel source, and
there's certainly no resampling going on there ... the card is given the
marching orders, and has to provide the data stream at that rate.
The maximum rate snd_emu10k1_capture.rate_max is 48000, so that's
probably the native rate in the card, and when we ask for it to run at
44100 the card is probably doing the resampling ... and the xruns
suggest it is doing it badly.
... in one system I test on, the motherboard audio is SiS SI7012, and it
doesn't run at anything but 48000. I'll run a test to see if it is the
input or output stream of the emu10k1 that is causing an xrun.
--
James Cameron
http://quozl.linux.org.au/
10 Aug
10 Aug
12:42 a.m.
On Mon, Aug 10, 2009 at 09:36:44AM +1000, James Cameron wrote:
... in one system I test on, the motherboard audio is
SiS SI7012, and it
doesn't run at anything but 48000. I'll run a test to see if it is the
input or output stream of the emu10k1 that is causing an xrun.
Test complete, no useful conclusion.
The method I used was to run jackd (from qjackctl) selecting the four
combinations of input and output against the two sound "cards", all at
44100 Hz. Then I started the transport and took note of the xruns rate.
a. Creative Labs SB Live! (module snd_emu10k1) as input and output,
failed, one xrun per 28 minutes.
b. SiS SI7012 (module snd_intel8x0) as input and output, passed, no
xruns.
c. Creative Labs SB Live! as input, SiS SI7012 as output, failed, 150
xruns over 30 seconds.
d. Creative Labs SB Live! as output, SiS SI7012 as input, failed, 40
xruns over 90 minutes.
Based on these results it was not possible to blame a specific
direction, though the higher rate of xruns when the SB Live! was used as
input may be significant. It fits the theory that the card resamples
and sometimes gets it wrong.
(And it takes jackd's careful method of determining and logging xruns
that makes us notice it).
--
James Cameron
http://quozl.linux.org.au/
9 Aug
9 Aug
9:57 a.m.
On Sunday 09 August 2009 14:36:26 Paul Davis wrote:
Since the switch to 48000 does get rid of the regular
periodic Xruns (others
may still occurs--not a rt-patched kernel), if this hypothesis not
appropriate, what was causing the Xruns (which the fact of their occurance was
not particularly hardware or kernel dependent though the period may have
been)?
Ken - again, no picking on your personally, just want
to clarify some
misconceptions for the record ...
On Fri, Aug 7, 2009 at 10:16 PM, Ken Restivo<ken(a)restivo.org> wrote:
If I am playing a
44100 file through xmms->jack (set to 48000) to default hw
out (hw:0 ?)--it sounds 100% OK so something is doing the resampling. The old
xmms?
That makes sense to me. The question I have now
is: who or what is doing
the resampling? Is it the card, internally? Or ALSA? If it's ALSA doing
the resampling, then the problem is likely the driver for the card.
no ALSA driver that i am aware of does resampling. however, libasound,
the ALSA library used by all ALSA applications (including JACK when
run with the ALSA backend) can resample if you use a device name that
permits it. the most common device name for this is something like
"plughw:N", which will do resampling if the underlying hardware does
not support the sample rate you ask for. it is not particularly high
quality resampling. if you use the "hw:N" device name, as is
recommended for JACK, no resampling will ever occur in software. Wherever it is, either ALSA driver or the
card's firmware or hardware, it
may be a 32-bit or 16-bit overflow. When audio cards are running in
normal mode, they just sit there most of the time unless you give them
audio. But with JACK running, the card is constantly being fed something
(zeroes? I haven't looked to find out what exactly) all the time. You'll
notice your interrupt counter going up and up when JACK is running, even
if no sound is coming out, for instance.
whenever you start an audio interface, it is running until you stop
it. perhaps you mean that other programs don't keep the interface open
when they are not playing audio. that would vary on a case by case
basis. ALSA also permits the app to leave the card running without the
app feeding anymore data - the app tells ALSA how to handle the
requirement to refill the card's data buffer - but i doubt if many
apps use this part of the ALSA API. in addition,
So my guess is that, every 14 minutes, enough
frames are pumped to the
card for that int/long/whatever to overflow. The strange sounds might be
as it gets close to that overflow point.
nothing is going to overflow for hours. and when it does, nothing
happens. you're just going to have trust this hand-waving assertion,
and i'm willing to be proven wrong in the case of a particular
driver/hw combination.
8 Aug
8 Aug
8:13 p.m.
Arnold Krille wrote:
Hi,
On Friday 07 August 2009 14:54:30 James Stone wrote:
48K is the rate the onboard Intel sound on this laptop runs.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
In the end, I tracked down my 14 minute xruns to
running the SBLive at
44100 instead of 48000.. I wonder if that would help with the OP problem?
Now, is this a bug with jack (v 0.116) or just a design problem with the
SBLive? I know the SBLive runs at 48000, and has to be resampled (or
something similar that I don't understand) to run at 44100, but surely
that shouldn't cause xruns.. The slow build of static before the xrun
now makes much more sense to me!
I think this could be the problem also for the OP! Nowadays many sound devices
just work with fixed 48000kHz and resample when opened with other rates...
3:26 a.m.
On Fri, Aug 07, 2009 at 01:54:30PM +0100, James Stone wrote:
Now, is this a bug with jack (v 0.116) or just a
design problem with the
SBLive? I know the SBLive runs at 48000, and has to be resampled (or
something similar that I don't understand) to run at 44100, but surely
that shouldn't cause xruns.. [...]
Interesting. My desktop has emu10k1 module loaded for a PCI card, and I
think it is an SBLive kinda thing ... jackd is 0.116.2+svn359, kernel is
2.6.26-1-686 (Debian), and I too get regular xruns but at 28 minute
intervals, not 14 minute intervals ...
**** alsa_pcm: xrun of at least 0.009 msecs
12:57:02.364 XRUN callback (1).
13:26:00.463 XRUN callback (2).
**** alsa_pcm: xrun of at least 0.022 msecs
13:54:59.492 XRUN callback (3).
**** alsa_pcm: xrun of at least 0.029 msecs
14:23:58.077 XRUN callback (4).
**** alsa_pcm: xrun of at least 0.018 msecs
14:52:45.125 XRUN callback (5).
**** alsa_pcm: xrun of at least 0.034 msecs
15:21:37.605 XRUN callback (6).
**** alsa_pcm: xrun of at least 0.129 msecs
This is with jackd configured for 44100. I'll try 48000 and see if it
goes away.
--
James Cameron
http://quozl.linux.org.au/
5:29 a.m.
On Sat, Aug 08, 2009 at 03:25:53PM +1000, James Cameron wrote:
This is with jackd configured for 44100. I'll try
48000 and see if it
goes away.
It goes away. No other change to the system or environment, and no
xruns at all over two hours sample time.
--
James Cameron
http://quozl.linux.org.au/
5:53 p.m.
On Saturday 08 August 2009 10:29:28 James Cameron wrote:
On Sat, Aug 08, 2009 at 03:25:53PM +1000, James
Cameron wrote:
Wow. I really opened something here!
I did not know my old ensonic 1371 junker would even do 48000. (Indeed, it
will dutifully report 40099 if asked). I just set 48000. See if it cures it
for me too.
This is with jackd configured for 44100.
I'll try 48000 and see if it
goes away.
It goes away. No other change to the system or environment, and no
xruns at all over two hours sample time.
9:57 p.m.
I ended up running the test for five and a half hours and no xruns.
--
James Cameron
http://quozl.linux.org.au/
5588
days inactive
5591
days old
linux-audio-user@lists.linuxaudio.org
33 comments
11 participants
participants (11)
-
Arnold Krille -
cal -
Dave Phillips -
david -
David Baron -
James Cameron -
James Stone -
Ken Restivo -
Patrick Shirkey -
Paul Davis -
Peder Hedlund