[PD] jack

[pix]

On Thu, 27 Mar 2003 19:43:13 +0100 (CET)
guenter geiger <geiger at xdv.org> wrote:

> On Thu, 27 Mar 2003, pix wrote:
> > finally success, using the latest devel_0_36 checkout, and the jack
> > 0.50 from debian ...
> >
> > actually what was making me think that it wasn't working was that i
> > needed to set "-n 3" to avoid getting staticy noise with my emi2|6.
> 
> yes, you have to get your settings right with jack ...

yeah.. i just saw a note on an alsa page, that you should set the
-p(eriod) to a multiple of 48 when using the emi2|6 (to fit the native
sample rate). but setting -p to anything other than a power of 2 gets pd
to spew out "partialread" error messages. i also remember the original
jack patch saying that you need to change the DACBLKSIZE in m_imp.h, but
changing it to anything other than a power of 2 also causes a consistency
check error.

not so important, would probably just help with latency. by the way,
anyone reading who cares, i got it down to 46ms with -n 3 -p 512.

> > i can now use all 6 channels of my emi2|6 (athough you have to hook
> > them up manually with jack_connect).
> 
> oops. thats a bug. fixed in CVS.

ah cool.

i also noticed that if you set -outchannels >2 and only open a normal
stereo dac~ object, you get noise on the rest of the channels.

> > i get 92ms latency, it looks like that would be about 32ms if i used
> > alsa directly (but i get terrible "continuity"). just mentioning that
> > incase anyone is interested. i personally don't do anything that
> > requires low latency.
> >
> > i also noticed that using a realtime jack and a realtime pd, i could
> > do pretty much anything on the machine without interrupting audio. but
> > if i tried to draw on a graph in pd, i still get audio dropouts (well,
> > crackles and A/D/A sync errors). if you ask me, that seems very wrong.
> 
> yes, drawing in arrays is the worst thing you can do together
> with selecting several objects and moving them around.
> 
> This is a problem of the pd<->GUI connection and how array
> drawing and updating is handled in pd ATM.

should i avoid reading too much into "ATM"? ;)

the idea of skimping on the interface reminds me far too much of doing
purely midi controlled csound/sfront patches.

pix.