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@xxxxxxxx> 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@xxxxxxxxxxx> 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 > >
