Hi,
I haven't followed this thread until now. It reminds me of a problem I
was seeing with my system. It turned out I had to enable DMA or a
specific associated flag in the kernel... Are you 100% certain your
kernel is setup for lowlat with *your* hardware?
It took me ages to figure out why it was happening for me and your
problem is very similar to what I was experiencing...
Cheers.
I. E. Smith-Heisters wrote:
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
>
>
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://lau.linuxaudio.org - The Linux Audio Users guide
========================================
"Anything your mind can see you can manifest physically, then it will
become reality" - Macka B
