16 Dec
2010
16 Dec
'10
3:21 a.m.
Hello, I'm looking for some advice for an interesting symptom of
putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
This sound card has four physical outputs which are mapped to two 2
channel ALSA streams rather than one four channel stream. I used the
ALSA multi plugin to combine these two streams into a single pcm
device so JACK can interface with all four outputs. It is working
nicely.
Despite no perceptible problems in sound quality or latency, jackd is
printing hundreds of XRUN callback warnings to the message console
each second! I can operate the system perfectly fine, run multiple
applications, connect them to the four virtual outputs with no audible
timing issues.
What is the meaning of this many XRUN callbacks per second? What kind
of performance will this impact if not sound playback?
Thanks for your help,
Lee Azzarello
16 Dec
16 Dec
7:02 a.m.
On Thu, Dec 16, 2010 at 4:21 AM, Lee Azzarello <lee(a)rockingtiger.com> wrote:
Hello, I'm looking for some advice for an
interesting symptom of
putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
I have no idea what might be happening, but an alternative to use
several alsa devices in jack would be the alsa_in and alsa_out
utilities shipped with jack, perhaps that will give you less trouble?
Luis
11:58 a.m.
On Thu, Dec 16, 2010 at 08:02:29AM +0100, Luis Garrido wrote:
On Thu, Dec 16, 2010 at 4:21 AM, Lee Azzarello
<lee(a)rockingtiger.com> wrote:
hmm... the interesting thing is that he actually claims to not have
trouble. he only gets xrun callbacks. this is weird.
Hello, I'm looking for some advice for an
interesting symptom of
putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
I have no idea what might be happening, but an alternative to use
several alsa devices in jack would be the alsa_in and alsa_out
utilities shipped with jack, perhaps that will give you less trouble?
Luis
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
6:36 p.m.
On Thu, Dec 16, 2010 at 6:58 AM, torbenh <torbenh(a)gmx.de> wrote:
On Thu, Dec 16, 2010 at 08:02:29AM +0100, Luis Garrido
wrote:
It is weird indeed. More detail:
1) My test parameters included only playback among multiple
applications, no recording nor duplex playback/record
2) I'm running Debian testing with the standard kernel on a Thinkpad X61
3) I considered the test successful when I could play back mp3s
continuously for over an hour while generating a test tone from Pure
Data at the same time. I also tested quitting and restarting PD while
alsaplayer continued to play back sound
I'll test the alsa_(in|out) utilities later today.
-lee
On Thu, Dec 16, 2010 at 4:21 AM, Lee Azzarello
<lee(a)rockingtiger.com> wrote:
hmm... the interesting thing is that he actually claims to not have
trouble. he only gets xrun callbacks. this is weird. Hello, I'm looking for some advice for an
interesting symptom of
putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
I have no idea what might be happening, but an alternative to use
several alsa devices in jack would be the alsa_in and alsa_out
utilities shipped with jack, perhaps that will give you less trouble?
7:49 p.m.
On Thu, Dec 16, 2010 at 1:36 PM, Lee Azzarello <lee(a)rockingtiger.com> wrote:
On Thu, Dec 16, 2010 at 6:58 AM, torbenh
<torbenh(a)gmx.de> wrote:
Great success! alsa_out on the second device exposes those two
additional channels to JACK and I can connect any application to them
without jackd printing messages about xrun callbacks. Thanks for your
help. Final thoughts:
I was initially attracted to the ALSA multi plugin because it is
managed by the kernel and I only have to interact with it once,
through a configuration file. alsa_out requires a service to be run
after jackd is started. I realize there are many ways to do this. In
the effort of simplicity, what are the best practices for managing
both interactive and non interactive JACK clients without spending a
bunch of time manually "initializing the patchbay" before a session?
-lee
On Thu, Dec 16, 2010 at 08:02:29AM +0100, Luis
Garrido wrote:
I'll test the alsa_(in|out) utilities later today. On Thu, Dec 16, 2010 at 4:21 AM, Lee Azzarello
<lee(a)rockingtiger.com> wrote:
hmm... the interesting thing is that he actually claims to not have
trouble. he only gets xrun callbacks. this is weird. Hello, I'm looking for some advice for an
interesting symptom of
putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
I have no idea what might be happening, but an alternative to use
several alsa devices in jack would be the alsa_in and alsa_out
utilities shipped with jack, perhaps that will give you less trouble?
8:13 p.m.
On Thu, Dec 16, 2010 at 8:49 PM, Lee Azzarello <lee(a)rockingtiger.com> wrote:
the effort of simplicity, what are the best practices
for managing
both interactive and non interactive JACK clients without spending a
bunch of time manually "initializing the patchbay" before a session?
Right off the bat you could:
1) Use a shell script from a terminal.
2) Use qjackctl scripting features (Setup, Options tab).
Luis
8:19 p.m.
On Thu, Dec 16, 2010 at 3:13 PM, Luis Garrido
<luisgarrido(a)users.sourceforge.net> wrote:
On Thu, Dec 16, 2010 at 8:49 PM, Lee Azzarello
<lee(a)rockingtiger.com> wrote:
may i direct everyone's attention to:
http://jackaudio.org/http://www.rncbc.org/drupal/node/76
the effort of simplicity, what are the best
practices for managing
both interactive and non interactive JACK clients without spending a
bunch of time manually "initializing the patchbay" before a session?
Right off the bat you could:
1) Use a shell script from a terminal.
2) Use qjackctl scripting features (Setup, Options tab). 
8:24 p.m.
On Thu, 16 Dec 2010, Paul Davis wrote:
may i direct everyone's attention to:
http://jackaudio.org/http://www.rncbc.org/drupal/node/76
...or even here: http://www.rncbc.org/drupal/node/76
:-)
-gabriel
18 Dec
18 Dec
2:16 p.m.
On 12/16/2010 08:49 PM, Lee Azzarello wrote:
On Thu, Dec 16, 2010 at 1:36 PM, Lee Azzarello
<lee(a)rockingtiger.com> wrote:
torben, i wonder: will alsa_[in|out] be perfectly bit-transparent when
the two interfaces it bridges are externally synced, or will its
tracking algorithm keep oscillating around the correct samplerate?
On Thu, Dec 16, 2010 at 6:58 AM, torbenh
<torbenh(a)gmx.de> wrote:
Great success! alsa_out on the second device exposes those two
additional channels to JACK and I can connect any application to them
without jackd printing messages about xrun callbacks. On Thu, Dec 16, 2010 at 08:02:29AM +0100, Luis
Garrido wrote:
I'll test the alsa_(in|out) utilities later today. On Thu, Dec 16, 2010 at 4:21 AM, Lee Azzarello
<lee(a)rockingtiger.com> wrote:
> Hello, I'm looking for some advice for an interesting symptom of
> putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
I have no idea what might be happening, but an alternative to use
several alsa devices in jack would be the alsa_in and alsa_out
utilities shipped with jack, perhaps that will give you less trouble?
hmm... the interesting thing is that he actually claims to not have
trouble. he only gets xrun callbacks. this is weird.
20 Dec
20 Dec
8:14 a.m.
On Sat, Dec 18, 2010 at 03:19:14PM +0100, Jörn Nettingsmeier wrote:
On 12/16/2010 08:49 PM, Lee Azzarello wrote:
it will oscilate, but the oscilation will get slower and slower,
and its about 0.00001% so this is going to be pretty good.
but its not perfect.
there are a bit of scheduler uncerteinties, which might perturbate the
timebase.
if your interfaces are synced just use the pcm multi approach.
if you dont care for bit-transparency, and dont want to edit a config
file, use alsa_io.
the main purpose of alsa_io is jackd running with a jittery timebase.
and i prefer optimizing it at that end.
On Thu, Dec 16, 2010 at 1:36 PM, Lee Azzarello
<lee(a)rockingtiger.com> wrote:
torben, i wonder: will alsa_[in|out] be perfectly bit-transparent when
the two interfaces it bridges are externally synced, or will its
tracking algorithm keep oscillating around the correct samplerate? On Thu, Dec 16, 2010 at 6:58 AM, torbenh
<torbenh(a)gmx.de> wrote:
Great success! alsa_out on the second device exposes those two
additional channels to JACK and I can connect any application to them
without jackd printing messages about xrun callbacks. On Thu, Dec 16, 2010 at 08:02:29AM +0100, Luis
Garrido wrote:
> On Thu, Dec 16, 2010 at 4:21 AM, Lee Azzarello <lee(a)rockingtiger.com> wrote:
>> Hello, I'm looking for some advice for an interesting symptom of
>> putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
>
> I have no idea what might be happening, but an alternative to use
> several alsa devices in jack would be the alsa_in and alsa_out
> utilities shipped with jack, perhaps that will give you less trouble?
hmm... the interesting thing is that he actually claims to not have
trouble. he only gets xrun callbacks. this is weird.
I'll test the alsa_(in|out) utilities later today.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
1:34 p.m.
On 12/20/2010 09:14 AM, torbenh wrote:
absolutely! i was just curious...
torben, i
wonder: will alsa_[in|out] be perfectly bit-transparent when
the two interfaces it bridges are externally synced, or will its
tracking algorithm keep oscillating around the correct samplerate?
it will oscilate, but the oscilation will get slower and slower,
and its about 0.00001% so this is going to be pretty good.
but its not perfect.
there are a bit of scheduler uncerteinties, which might perturbate the
timebase.
if your interfaces are synced just use the pcm multi approach.
if you dont care for bit-transparency, and dont want to edit a config
file, use alsa_io.
the main purpose of alsa_io is jackd running with a jittery timebase.
and i prefer optimizing it at that end.
14 Jan
14 Jan
9:36 p.m.
hi!
sorry for warming up an older thread here...
On 12/16/2010 04:21 AM, Lee Azzarello wrote:
Hello, I'm looking for some advice for an
interesting symptom of
putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
This sound card has four physical outputs which are mapped to two 2
channel ALSA streams rather than one four channel stream. I used the
ALSA multi plugin to combine these two streams into a single pcm
device so JACK can interface with all four outputs. It is working
nicely.
Despite no perceptible problems in sound quality or latency, jackd is
printing hundreds of XRUN callback warnings to the message console
each second! I can operate the system perfectly fine, run multiple
applications, connect them to the four virtual outputs with no audible
timing issues.
What is the meaning of this many XRUN callbacks per second? What kind
of performance will this impact if not sound playback?
i've just tried to link a hdspm (using faberman's driver) and an ancient
digi9652 into a monster 90 channel device.
my .asoundrc looks like this:
pcm.multi {
type multi;
# the hdspm: first 64 channels
slaves.a.pcm "hw:2,0";
slaves.a.channels 64;
# the digi9652: last 26 channels
slaves.b.pcm "hw:1,0";
slaves.b.channels 26;
bindings.0.slave a;
bindings.0.channel 0;
...
bindings.63.slave a;
bindings.63.channel 63;
bindings.65.slave b;
bindings.65.channel 0;
...
bindings.90.slave b;
bindings.90.channel 1;
}
ctl.multi {
type hw;
card 2;
}
the two cards are synced via wordclock at 48k, the hdspm is the master.
miraculously enough, i can actually start jack with this device:
22:06:48.259 ALSA connection graph change.
22:06:48.393 ALSA connection change.
22:11:42.707 JACK is starting...
22:11:42.708 /usr/local/bin/jackd -P80 -p2048 -t9999 -u -dalsa -dmulti
-r48000 -p1024 -n2 -zs
Cannot connect to server socket err = Connection refused
Cannot connect to server socket
jack server is not running or cannot be started
no message buffer overruns
no message buffer overruns
jackdmp 1.9.7
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2010 Grame.
jackdmp 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 server starting in realtime mode with priority 80
22:11:42.844 JACK was started with PID=28260.
creating alsa driver ... multi|multi|1024|2|48000|0|0|nomon|swmeter|-|32bit
Using ALSA driver HDSPM running on card 2 - RME MADI S/N 0xc62105 at
0xf9ff0000, irq 19
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
22:11:45.082 JACK connection change.
22:11:45.220 Server configuration saved to "/home/nettings/.jackdrc".
22:11:45.222 Statistics reset.
22:11:45.238 Client activated.
22:11:45.341 XRUN callback (1).
22:11:45.341 JACK connection graph change.
and like lee, i immediately get hundreds of "little xruns", i.e. the
type that qjackctl displays in parentheses. the "big" xrun count stays
at zero. meanwhile, i'm getting these errors in the log:
JackPosixMutex::Unlock res = 1
JackPosixMutex::Unlock res = 1
JackPosixMutex::Unlock res = 1
i had it crash once when loading a really demanding session, but with
another average ardour project, it has now played fine and without
glitches for 10 minutes or so, while the xrun count goes through the roof.
i wonder what's really going on here, but i'm also happy i can combine
those two cards which means i finally get a Grand Unified interface
without the need to restart jack, ever again :)
best,
jörn
10:08 p.m.
On 01/14/2011 10:39 PM, Jörn Nettingsmeier wrote:
i had it crash once when loading a really demanding
session, but with
another average ardour project, it has now played fine and without
glitches for 10 minutes or so, while the xrun count goes through the roof.
alas. i spoke to soon:
after i added a 6x1 convolver and an ambdec instance
jack2 bails out reproducibly after a couple minutes more, with a
"floating point exception". so more testing.
meanwhile, i'd like to know what these xruns are, and i wouldn't be too
surprised if the eventual crash is actually related to the message
buffer or some internal error counter wrapping...
11:34 p.m.
On 01/14/2011 02:12 PM, Jörn Nettingsmeier wrote:
On 01/14/2011 10:39 PM, Jörn Nettingsmeier wrote:
I would be interested in that as well...
I tried a few months ago to link an hdsp madi and a 9652 (sounds
familiar? :-) and failed. I don't remember the details and I did not
have time to try to debug it but it never worked - this was for our
OpenMixer setup.
I ended up connecting to the "smaller" card through jack2's internal
audioadapter client. That is not a bit transparent operation and uses up
cpu as it does resampling (the two cards are locked of course) but it
was good enough, at least for a while...
-- Fernando
i had it crash once when loading a really
demanding session, but with
another average ardour project, it has now played fine and without
glitches for 10 minutes or so, while the xrun count goes through the roof.
alas. i spoke to soon:
after i added a 6x1 convolver and an ambdec instance
jack2 bails out reproducibly after a couple minutes more, with a
"floating point exception". so more testing.
meanwhile, i'd like to know what these xruns are, and i wouldn't be too
surprised if the eventual crash is actually related to the message
buffer or some internal error counter wrapping...
11:51 p.m.
On 01/14/2011 11:12 PM, Jörn Nettingsmeier wrote:
On 01/14/2011 10:39 PM, Jörn Nettingsmeier wrote:
jack2 gets nervous when i use a session with four jconvolver instances:
JackPosixMutex::Unlock res = 1
Unknown request 4294967295
jackd: ../common/JackGraphManager.cpp:45: void
Jack::JackGraphManager::AssertPort(jack_port_id_t): Assertion
`port_index < fPortMax' failed.
Aborted
the cpu is not maxed out, afaics.
tschack handles this scenario just fine, and it doesn't spew error
messages on the console. if i monitor it in qjackctl, the xrun count
increases at the usual rate, though.
btw: qjackctl becomes a major cpu burden in this pathological case.
lookes like it's the error messages. i've seen it at up to 40% of one core.
i had it crash once when loading a really
demanding session, but with
another average ardour project, it has now played fine and without
glitches for 10 minutes or so, while the xrun count goes through the roof.
alas. i spoke to soon:
after i added a 6x1 convolver and an ambdec instance
jack2 bails out reproducibly after a couple minutes more, with a
"floating point exception". so more testing.
meanwhile, i'd like to know what these xruns are, and i wouldn't be too
surprised if the eventual crash is actually related to the message
buffer or some internal error counter wrapping... 
10:15 p.m.
On 01/15/2011 08:39 AM, Jörn Nettingsmeier wrote:
and like lee, i immediately get hundreds of
"little xruns", i.e. the
type that qjackctl displays in parentheses. the "big" xrun count stays
at zero. meanwhile, i'm getting these errors in the log:
JackPosixMutex::Unlock res = 1
JackPosixMutex::Unlock res = 1
JackPosixMutex::Unlock res = 1
this has always occured with multi arrays and SMP for me with my 4
C-Ports. UP doesn't do this. Single devices don't do this. All jacks
are affected. Could it be alsa?
g.
10:39 p.m.
2011/1/14 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
and like lee, i immediately get hundreds of
"little xruns", i.e. the
type that qjackctl displays in parentheses. the "big" xrun count stays
at zero. meanwhile, i'm getting these errors in the log:
Just for reference, here Rui explains the meaning of these two numbers:
http://permalink.gmane.org/gmane.comp.audio.jackit/19714
In short, just ignore the first one
L
5099
days inactive
5128
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
8 participants
participants (8)
-
Fernando Lopez-Lezcano -
Gabriel M. Beddingfield -
Geoff Beasley -
Jörn Nettingsmeier -
Lee Azzarello -
Luis Garrido -
Paul Davis -
torbenh