16 Jun
2006
16 Jun
'06
7:14 p.m.
Well.. just in case someone sees something that I don't, I thought I'd
include a transcript of a failed session. But I don't see any errors
there, except that it crashes, of course.
# jackd -v -R -dalsa -dhw:0 -r48000 -p1024 -n2 -S
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_alsa.so
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_dummy.so
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_oss.so
jackd 0.100.0
Copyright 2001-2005 Paul Davis 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.
server `default' registered
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|16bit
control device hw:0
registered builtin port type 32 bit float mono audio
running with uid=0 and euid=0, will not try to use capabilites
new client: alsa_pcm, id = 1 type 1 @ 0x8058a78 fd = -1
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
new buffer size 1024
registered port alsa_pcm:capture_1, offset = 4096
registered port alsa_pcm:capture_2, offset = 8192
registered port alsa_pcm:playback_1, offset = 0
registered port alsa_pcm:playback_2, offset = 0
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
6316 waiting for signals
jackd watchdog: timeout - killing jackd
Aborted
#
Thanks for any tips you might have. I'm quite stumped. Either no one
has tried to use jack with an ICH7 family chipset (highly
unlikely--it's quite common), or no one's run into this problem, since
I can't find a single post about problems with ICH7 and Jack through
Google.
Thanks again,
ian
On 6/14/06, I. E. Smith-Heisters <public(a)0x09.com> wrote:
Okay, looked at it some more. When RT is enabled, jack
just locks up
and the watchdog terminates the process, regardless of the buffer
size. When RT is disabled the xruns are allowed to continue, and the
number of xruns decreases with a higher buffer size (but never go
below about 10/second). There's no evidence that RT mode has failed to
be set. This is all as root.
I am using the proprietary NVIDIA drivers, as gotten from the Ubuntu
repositories. I would be surprised if this had anything to do with it
though, since direct alsa works fine with the same xOrg drivers.
Unless, of course, there's some software conflict between the video
drivers and jack itself (as opposed to there being a hardware-level
conflict).
hmm....
thanks for the advice.
-Ian
On 6/13/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Tue, 2006-06-13 at 16:17 -0400, I. E.
Smith-Heisters wrote:
I've futzed around a bit more. I'd done
this before, but I'd forgotten
the exact results except that it didn't work. Tried all this both with
and without RT and 16bit mode forced:
upping frames/period to 4096 reduces the number of xruns to several/second.
upping periods/buffer to 3 still gives xruns, as well as "usecs
exceeds estimated spare time" messages.
upping periods/buffer to 4 makes initialization fail with "ALSA: got
smaller periods 2 than 4 for playback"
putting it into non-duplex (ie. playback only) has no effect on behavior.
So, yeah, that's why it's mysterious. In the past I sacrifice latency
for no xruns, and everything's dandy. Not so, this time...
Thanks for the suggestions.
Are you saying that RT mode has no effect on the xruns? I find this
hard to believe.
Check the messages from JACK - maybe it's failing to set RT mode (thisis
a bug that's fixed in the development tree).
Try these tests in RT mode as root to be sure.
Are you using the proprietary ATI or Nvidia drivers?
Lee