Hello Paul,
thanks for your reply
Am Samstag, 16. Juni 2007 04:14 schrieb Paul Coccoli:
**** alsa_pcm:
xrun of at least 51.514 msecs
**** alsa_pcm: xrun of at least 12.643 msecs
subgraph starting at soundroom timed out (subgraph_wait_fd=9, status = 0,
state = Running)
----------- schnipp
the xruns only appear while load sounds.
kernelversion is
Linux soundroom 2.6.15.6 #7 SMP PREEMPT Fri Jun 16 22:18:26 GMT 2006 i686
unknown unknown GNU/Linux
more /proc/asound/cards
0 [Gina3G ]: Echo_Echo3G - Gina3G
Gina3G rev.0 (DSP56361) at 0xea000000 irq 50
1 [CK804 ]: NFORCE - NVidia CK804
NVidia CK804 with ALC850 at 0xea105000, irq 217
and i use the gina3G
and now the questions;
- is there any way, to get more infos out off jack
- any way to keep the app connected or a hint to avoid the disconnection
- some days ago i testet the jack version 0.103, but jack uses 100% cpu
without any app. just starting qjackctl showed that.
thanks very much for some hints. c~
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
How are you getting the loaded data from your file IO thread to your
jack thread? Are you blocking the jack thread somehow?
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
the jack thread isn't really working at that moment. It don't need to play
data. last weekend i have found the verbose flag and it gave me the following
infomation
----------------- schnipp
load = 50.5622 max usecs: 73296.000, spare = 0.000
load = 25.8530 max usecs: 244.000, spare = 21089.000
load = 13.4773 max usecs: 235.000, spare = 21098.000
load = 7.2871 max usecs: 234.000, spare = 21099.000
load = 4.1967 max usecs: 236.000, spare = 21097.000
**** alsa_pcm: xrun of at least 15.962 msecs
load = 4.6578 max usecs: 1092.000, spare = 20241.000
load = 2.8726 max usecs: 232.000, spare = 21101.000
load = 1.9895 max usecs: 236.000, spare = 21097.000
load = 1.5408 max usecs: 233.000, spare = 21100.000
load = 1.3470 max usecs: 246.000, spare = 21087.000
load = 1.2571 max usecs: 249.000, spare = 21084.000
subgraph starting at soundroom timed out (subgraph_wait_fd=9, status = 0,
state = Running)
at 15736534391 waiting on 9 for 78997 usecs, status = 1 sig = 15736455388 awa
= 15736460072 fin = 0 dur=0
client soundroom error: awake_at = 15736460072 state = 2 timed_out = 2
client failure: client soundroom state = Running errors = 1
removing client "soundroom" from the processing chain
DIS-connect alsa_pcm:capture_2 and soundroom:Rekordingmikro
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client soundroom: start_fd=7, execution_order=0.
client soundroom: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect alsa_pcm:capture_1 and soundroom:Raummikro
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
client soundroom: start_fd=7, execution_order=0.
client soundroom: wait_fd=9, execution_order=1 (last client).
-- jack_rechain_graph()
DIS-connect soundroom:rechts_hinten_out and alsa_pcm:playback_6
++ jack_rechain_graph():
[ and so forth .... ]
----------------------------------- schnipp
somewhere i have read, that this disconnect would be amount, if the CPU load
is to high. after blocking the loader thread to update the GUI, its getting
better.
looking/locking further c~
--
Conrad Berhörster
TONCAT