21 Jan
2004
21 Jan
'04
11:52 a.m.
Hi,
1) I'm using alsa 1.0.1 with the latest version of jackd on a via kt400
mobo (VT8377) and a VT8233 audio controller. I have the low-latency/premp
kernel patches as well as the capabilities patch applied to a 2.4.22
kernel. I get xruns like crazy that average around 0.09 msecs when running
jackd in duplex mode. These disapear when running in either capture or
playback mode. I had seen that there may be some issues with the via82xx
chipset and jackd on the alsa list, but no solutions or description of
what the actual problems were. Am I stuck in a duplex-free zone or is
there a way to work around this? Will this affect my ability to use ardour
as multitracking device using the mic/line-in, or will it only cripple my
ability to use other programs as jack slaves?
2) Even with the capabilities patch, I get the following error when
running jack as a normal user:
JACK: unable to mlock() port buffers: Operation not permitted
cannot set thread to real-time priority (FIFO/20) (1: Operation not
permitted)
cannot use real-time scheduling (FIFO/10) (1: Operation not permitted)
Any ideas?
Thanks!
Keith
21 Jan
21 Jan
2:20 p.m.
Keith Parkins wrote on Wed, 21-Jan-2004:
Hi,
1) I'm using alsa 1.0.1 with the latest version of jackd on a via kt400
mobo (VT8377) and a VT8233 audio controller. I have the low-latency/premp
kernel patches as well as the capabilities patch applied to a 2.4.22
kernel. I get xruns like crazy that average around 0.09 msecs when running
jackd in duplex mode. These disapear when running in either capture or
playback mode. I had seen that there may be some issues with the via82xx
chipset and jackd on the alsa list, but no solutions or description of
what the actual problems were. Am I stuck in a duplex-free zone or is
there a way to work around this? Will this affect my ability to use ardour
as multitracking device using the mic/line-in, or will it only cripple my
ability to use other programs as jack slaves?
What sample rate are you using? Try the other one, (48000 or 44100)
and see if it's any better.
2) Even with the capabilities patch, I get the
following error when
running jack as a normal user:
JACK: unable to mlock() port buffers: Operation not permitted
cannot set thread to real-time priority (FIFO/20) (1: Operation not
permitted)
cannot use real-time scheduling (FIFO/10) (1: Operation not permitted)
You need to run jackstart, instead of jackd to make use of the
capabilities patch. If you haven't been realtime, that might
explain your full-duplex overruns too.
jlc
2:39 p.m.
jackstart worked for setting the capabilities, but I'm still getting xruns
in duplex mode even with the sampling rate set to 44100.
On Wed, 21 Jan 2004, Jesse Chappell wrote:
Keith Parkins wrote on Wed, 21-Jan-2004:
Hi,
1) I'm using alsa 1.0.1 with the latest version of jackd on a via kt400
mobo (VT8377) and a VT8233 audio controller. I have the low-latency/premp
kernel patches as well as the capabilities patch applied to a 2.4.22
kernel. I get xruns like crazy that average around 0.09 msecs when running
jackd in duplex mode. These disapear when running in either capture or
playback mode. I had seen that there may be some issues with the via82xx
chipset and jackd on the alsa list, but no solutions or description of
what the actual problems were. Am I stuck in a duplex-free zone or is
there a way to work around this? Will this affect my ability to use ardour
as multitracking device using the mic/line-in, or will it only cripple my
ability to use other programs as jack slaves?
What sample rate are you using? Try the other one, (48000 or 44100)
and see if it's any better.
2) Even with the capabilities patch, I get the
following error when
running jack as a normal user:
JACK: unable to mlock() port buffers: Operation not permitted
cannot set thread to real-time priority (FIFO/20) (1: Operation not
permitted)
cannot use real-time scheduling (FIFO/10) (1: Operation not permitted)
You need to run jackstart, instead of jackd to make use of the
capabilities patch. If you haven't been realtime, that might
explain your full-duplex overruns too.
jlc
2:50 p.m.
On Wed, 2004-01-21 at 10:35, Keith Parkins wrote:
jackstart worked for setting the capabilities, but
I'm still getting xruns
in duplex mode even with the sampling rate set to 44100.
What results do you get with periods/buffer set higher?
For my 8235 I cannot run with 2 and 1024, but it works well even on an
unpatched kernel at 4 and 256. No xruns at all. I'm running remotely and
as a user using qjackctl.
In my experience it doesn't always seem to be about 'latency'. Sometimes
it's about finding the specific parameters that work well with the
specific chip.
Good luck,
Mark
3:52 p.m.
I've tried other parameters before to no avail.
I did notice this post on the alsa list:
http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg11011.html
and thought that maybe others had encountered this problem as well.
Can someone tell me what my limitations are going to be if I can't run
jack in duplex mode? Will I be able to user ardour on its own to do
multitracking from the line-in/mic?
Thanks!
Keith
On Wed, 21 Jan 2004, Mark Knecht wrote:
On Wed, 2004-01-21 at 10:35, Keith Parkins wrote:
jackstart worked for setting the capabilities,
but I'm still getting xruns
in duplex mode even with the sampling rate set to 44100.
What results do you get with periods/buffer set higher?
For my 8235 I cannot run with 2 and 1024, but it works well even on an
unpatched kernel at 4 and 256. No xruns at all. I'm running remotely and
as a user using qjackctl.
In my experience it doesn't always seem to be about 'latency'. Sometimes
it's about finding the specific parameters that work well with the
specific chip.
Good luck,
Mark
4:43 p.m.
I've tried other parameters before to no avail.
Too bad. Sorry. As was suggested, some of these less expensive chips have
limitations. You're fixed to specific sample rates, or block sizes. We all
have had to poke around at times looking for things that actually work.
Limitation of the hardware probably.
I did notice this post on the alsa list:
http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg11011.html
and thought that maybe others had encountered this problem as well.
You're most likely correct. Maybe there's an advantage to having an 8235.
Don't know. Seems to be OK for me. I don't use it with Jack much, but it
does run, and as I say, I'm getting 5mS reliably on an unpatched Gentoo
2.4.22 kernel.
Can someone tell me what my limitations are going to be if I can't run
jack in duplex mode? Will I be able to user ardour on its own to do
multitracking from the line-in/mic?
I think you'll see the limitations in qjackctl. IIRC, you'll only see inputs
or outputs in the patch bay/connections sections when you choose something
other than duplex. It's been a while since I've looked at this. Therefore
Ardour would only have access to what's visible.
Maybe try soft mode with Jack? I've never even tried that. Likely it won't
help you, and sorry if you've said you've tried that. Don't think I have
much more to offer.
Good luck,
Mark
7640
days inactive
7640
days old
linux-audio-user@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Jesse Chappell -
Keith Parkins -
Mark Knecht -
Mark Knecht