Hi, yes, I have the 1.9.5~dfsg-13 package installed and also tried the newest upstream version (rev 4008 which says version 1.9.6).
The same happens with a buffer size of 256, but it seems to go away or at least to be better with 2048. Nevertheless with jack1, I can go down to 64 under light load. RT prios are enabled, my /etc/security/limits.conf reads [USER] - memlock unlimited [USER] - rtprio 99 [USER] - nofile 100000 ( [USER] ist replaced with my user name) When I start jack with jackd -R -p512 -dalsa -r44100 -p128 -n2 -D -Chw:1 -Phw:1 -Xseq -zs and then in 2 other consoles alsa_in -dalsa -d hw:0 -c12 and alsa_out -dalsa -d hw:0 -c10 it seems to work (besides alsa_in telling me "delay = 2732", don't know what that means), but I don't know if I can trust it in terms of synchronization, same frames size etc... do you? Thanks a lot, Benjamin Am 13.05.2010 16:49, schrieb Adrian Knoth: > On Thu, May 13, 2010 at 12:20:45AM +0200, Benjamin Scherrer wrote: > > >> Hi, >> > Hi! > > >> package unusable to me. This is caused by an upstream bug which has >> been there for a long time (well, offcially I only reported it 3 days >> ago...). Jack2 crashes with my 2 M-Audio Delta1010LTs but works >> flawlessly with jack1. >> > Have you already tried with the 1.9.5-13 package? Your upstream ticket > is talking about 1.9.4. > > How about running jackd on top of your first card and add the second > card via alsa_in and alsa_out? Might not be as elegant as the combined > devices, but should work or at least produce more insight. > > Do you need to run with -p128? Are things more stable with higher > values? > > Basically, you're seeing xruns, the floating point exception might just > be a consequence, though your backtrace doesn't contain any sign of it. > > We surely need to get a complete backtrace. > > I assume you have RT prios enabled? > > > HTH > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
