[PD] jack periods 32 = no pd

[Winfried Ritsch]

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 at iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > > http://lists.puredata.info/listinfo/pd-list
> > 
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list


-- 
- 
--
- ao.Univ.Prof. DI Winfried Ritsch 
- ritsch at iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--