hi,
in my quest of lowering my round-trip latency, I am configuring Jack with: periods (buffer size): 32; nperiods: 2 / 3 (doesn't matter); rate 48000
when starting pd -rt -jack -channels 2 (-nosleep) = doesn't start.
other applications like amsynth, JAMin doesn't have this behaviour
(they works).
when using periods 64 then pd works.
?
- puredata@11h11.com puredata@11h11.com [2014-01-27 19:54]:
hi,
in my quest of lowering my round-trip latency, I am configuring Jack with: periods (buffer size): 32; nperiods: 2 / 3 (doesn't matter); rate 48000
when starting pd -rt -jack -channels 2 (-nosleep) = doesn't start. other applications like amsynth, JAMin doesn't have this behaviour (they works).
when using periods 64 then pd works.
i think I had the same problem recently, is there an error message output, possibly to the console when you start pd with 23 periods? Probably to the terminal upon starting pd from therein?
I didn't find a solution yet, I must say.
best, P
?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
pd -rt -jack -channels 2
priority 6 scheduling enabled.
priority 8 scheduling enabled.
Partial read
Partial read
...
pd: malloc.c:3822: _int_malloc: Assertion `(unsigned long)(size) >=
(unsigned long)(nb)' failed.
Pd: signal 6
psc@pscbox:~$ pdsend errorname: >>error writing "sock8": broken pipe<<
pdsend errorname: >>error writing "sock8": broken pipe<<
- puredata@11h11.com puredata@11h11.com [2014-01-27 21:24]:
pd -rt -jack -channels 2 priority 6 scheduling enabled. priority 8 scheduling enabled. Partial read Partial read ... pd: malloc.c:3822: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed. Pd: signal 6 psc@pscbox:~$ pdsend errorname: >>error writing "sock8": broken pipe<< pdsend errorname: >>error writing "sock8": broken pipe<<
Jep, I do get lines of
Partial read
[...]
followed by a
Segmentation fault
and pdsend errorname: >>error writing "sock7": broken pipe<<
Here's a backtrace from within gdb:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7f9b700 (LWP 22956)] 0x00007ffff6afc790 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt #0 0x00007ffff6afc790 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00000000004f1428 in pollprocess () #2 0x00007ffff75d1dbf in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0 #3 0x00007ffff7184e0e in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x00007ffff6aae0fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
I hope this is useful to anyone.
best, P
Probably that's so - but Pd should still be able to deal with the mismatch. OTOH, since Pd is built-in 64 blocksize, you wouldn't be able to reduce Pd's latency by reducing jack's blocksize below 64.
I'm not sure about this, but I believe that Pd running standalone (using ALSA driver) can achieve as low or perhaps slightly lower latency than Pd running under jack. This is only of interest if Pd's the only audio application you're running on that particular audio interface, however.
cheers Miller
On Tue, Jan 28, 2014 at 12:33:43AM -0500, puredata@11h11.com wrote:
hum i might have an idea why: is it because pd works in 64 blocks?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
- Miller Puckette msp@ucsd.edu [2014-01-28 00:02]:
Probably that's so - but Pd should still be able to deal with the mismatch. OTOH, since Pd is built-in 64 blocksize, you wouldn't be able to reduce Pd's latency by reducing jack's blocksize below 64.
Allright, then I can live without going lower.
I'm not sure about this, but I believe that Pd running standalone (using ALSA driver) can achieve as low or perhaps slightly lower latency than Pd running under jack. This is only of interest if Pd's the only audio application you're running on that particular audio interface, however.
I can currently start pd using -alsa -rt -audiobuf 2 and get click-free performance, as long as I don't the classic "Select all.." and move things around in Tcl/Tk, which of course causes drop-outs. Haven't measured latency with that setup yet, but it sure sounds promising. Using the oss emulation of alsa works too, but slightly more clicks when moving objects on the canvas.
best, P
- Peter P. p8rpp@aol.com [2014-01-28 00:35]:
- Miller Puckette msp@ucsd.edu [2014-01-28 00:02]:
Probably that's so - but Pd should still be able to deal with the mismatch. OTOH, since Pd is built-in 64 blocksize, you wouldn't be able to reduce Pd's latency by reducing jack's blocksize below 64.
Allright, then I can live without going lower.
I'm not sure about this, but I believe that Pd running standalone (using ALSA driver) can achieve as low or perhaps slightly lower latency than Pd running under jack. This is only of interest if Pd's the only audio application you're running on that particular audio interface, however.
I can currently start pd using -alsa -rt -audiobuf 2 and get click-free performance, as long as I don't the classic "Select all.." and move things around in Tcl/Tk, which of course causes drop-outs. Haven't measured latency with that setup yet, but it sure sounds promising. Using the oss emulation of alsa works too, but slightly more clicks when moving objects on the canvas.
Made a latency test with pd's own latency testing patch /usr/local/lib/pd/doc/7.stuff/tools/latency.pd
-alsa -rt -audiobuf 2 -channels 18 on an HDSPe card with Multiface and a loopback analogue cable gives 6.5ms, which I consider great!
Interestingly Pd gives this latency value regardless of setting -audiobuf to values 1-6, which I suppose is because of rounding this value to something usable by the dsp part. Pd also reports on startup "...buffer_time 2902 us opened" "using mmap audio interface"
Now what is weird, is that I can't get clean audio under alsa with any values larger than -audiobuf 6. The sound is very distorted.
Using the -oss emulation and -rt, clean audio is available for values larger than -audiobuf 2 such as:
-audiobuf 3 with measured latency of 7.9ms (Pd choses blocksze 56) -audiobuf 5 with measured latency of 9.4ms (Pd choses blocksze 56) -audiobuf 6 with measured latency of 10.9ms (Pd choses blocksze 56) and so on.
Oh this is on a Debian system running kernel 3.2.0-4-rt-amd64
Nice that Pd can do so low latencies, but that's a strange thing about alsa though...
best, P
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK... that's really quite strange indeed. FWIW the 'mmap' alsa code, as far as I know, is only selected for RME devices. I don't have any of those handy so have little way to check any of this on my end. It was written by Winfried Ritsch a decade or more ago :)
Miller
Made a latency test with pd's own latency testing patch /usr/local/lib/pd/doc/7.stuff/tools/latency.pd
-alsa -rt -audiobuf 2 -channels 18 on an HDSPe card with Multiface and a loopback analogue cable gives 6.5ms, which I consider great!
Interestingly Pd gives this latency value regardless of setting -audiobuf to values 1-6, which I suppose is because of rounding this value to something usable by the dsp part. Pd also reports on startup "...buffer_time 2902 us opened" "using mmap audio interface"
Now what is weird, is that I can't get clean audio under alsa with any values larger than -audiobuf 6. The sound is very distorted.
Using the -oss emulation and -rt, clean audio is available for values larger than -audiobuf 2 such as:
-audiobuf 3 with measured latency of 7.9ms (Pd choses blocksze 56) -audiobuf 5 with measured latency of 9.4ms (Pd choses blocksze 56) -audiobuf 6 with measured latency of 10.9ms (Pd choses blocksze 56) and so on.
Oh this is on a Debian system running kernel 3.2.0-4-rt-amd64
Nice that Pd can do so low latencies, but that's a strange thing about alsa though...
best, P
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
I just got to my old computer in my atelier which such a card. Code was written 2003 where no HDSPe was available, mainly to use more than one RME9652 card with low latency, nowadays this can be done also with other methods (jackd).
mmap access is working ok on my computer (I don't use rt-patched kernels, mostly never needed), anyway it sets the buffer it get closest to fulfill the audiobuf settings, ..., hmm, ... but it doesn't, instead uses always the smallest one: the sys_blocksize=64, using 128 (minimum of card). So if your computer is to slow it will make bad sound:
pdsyschedadvance=6000 us(264 Samples)so buffertime max should be this=0or sys_blocksize=64 (samples) to use buffersize=64
don't know why this bug never was detected, amyway with bigger -blocksize maybe bigger audiobufs works.
I will inspect this more next week and see if I can propse a patch.
mfg winfried
PS: Anyway its great it's works somehow after 10years without code change ;-)))
Am Dienstag, 28. Januar 2014, 21:24:43 schrieb Miller Puckette:
OK... that's really quite strange indeed. FWIW the 'mmap' alsa code, as far as I know, is only selected for RME devices. I don't have any of those handy so have little way to check any of this on my end. It was written by Winfried Ritsch a decade or more ago :)
Miller
Made a latency test with pd's own latency testing patch /usr/local/lib/pd/doc/7.stuff/tools/latency.pd
-alsa -rt -audiobuf 2 -channels 18 on an HDSPe card with Multiface and a loopback analogue cable gives 6.5ms, which I consider great!
Interestingly Pd gives this latency value regardless of setting -audiobuf to values 1-6, which I suppose is because of rounding this value to something usable by the dsp part. Pd also reports on startup "...buffer_time 2902 us opened" "using mmap audio interface"
Now what is weird, is that I can't get clean audio under alsa with any values larger than -audiobuf 6. The sound is very distorted.
Using the -oss emulation and -rt, clean audio is available for values larger than -audiobuf 2 such as:
-audiobuf 3 with measured latency of 7.9ms (Pd choses blocksze 56) -audiobuf 5 with measured latency of 9.4ms (Pd choses blocksze 56) -audiobuf 6 with measured latency of 10.9ms (Pd choses blocksze 56) and so on.
Oh this is on a Debian system running kernel 3.2.0-4-rt-amd64
Nice that Pd can do so low latencies, but that's a strange thing about alsa though...
best, P
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Miller Puckette -
Peter P. -
puredata＠11h11.com -
Winfried Ritsch