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
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,

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?

pkg-multimedia-maintainers mailing list

Reply via email to