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