[PlanetCCRMA] Realtime PD Troubles

[derek holzer]

Hi Scott,

You might find a bit of support on the PD list for this question. But I 
can throw a few suggestions here as well.

If you aren't using this already, I suggest making a .pdrc file in your 
home directory, which contains all your startup options. These options 
are visible when you type pd --help.

PD will not run with -rt unless you are root or sudo, so Jack will also 
need to be run as root or sudo to do it. I don't know of a workaround 
for this, probably better to ask on PD list.

As sudo, I run with both -rt and -jack flags, no problemo.

You can start PD with this argument:

-channels ...    -- specify both input and output channels

to specify how many channels in and out, or

-inchannels ...  -- audio input channels (by device, like "2" or "16,8")
-outchannels ... -- number of audio out channels (same)

for different numbers of ins and outs. Note that with Jack, this number 
can be greater than your available hardware channels, so rock out!

Finally, if DIO errors are still a problem when running -rt, then you 
need to use this argument:

-audiobuf <n>    -- specify size of audio buffer in msec

or maybe even this one:

-blocksize <n>   -- specify audio I/O block size in sample frames

to tinker with it. Audiobuf generally solves the problem if set high 
enough. You are correct in thinking that this is totally independent of 
Jack. It happens before the audio even gets there.

A list of small things to improve PD performance that I posted to the PD 
list a while back:

---use your .pdrc file to your benefit!
---increase your buffer size in PD
---increase your frames per period in Jack
---run at 44100KHz instead of Linux-default 48000KHz sampling rate
---trying running as sudo or root and see if it makes a difference
---always use the -rt flag in PD
---always use the -realtime mode in Jack.
---make sure you have low latency kernel with capabilties patch [CCRMA 
should have that covered]
---do you need all those channels in PD? Try using the -channels flag.
---investigate ways to change the latency of your IRQs and the priority 
of processes [renice, for example in the latter case]
---don't run any apps which make constant updates to the screen [such as 
Gkrell system monitor, or anything with animations!] while PDing.
---keep your patches clean! Visible arrays of samples, for example, are 
death to audio performance. Put things in subpatches, and ask yourself 
how many graphical elements are really *necessary* for your patch to 
run. Graphics which are updated frequently by PD are just as destructive 
to sound as graphics in other applications!

good luck,
D.

J. Scott Amort wrote:
> Thanks Fernando,
> 
> On Mon, 2004-01-12 at 16:50, Fernando Pablo Lopez-Lezcano wrote:
> 
>>I think you are trying for mutually incompatible realtime options. 
> 
> 
> Apparently that was the case.  You learn something new every day...
> 
> 
>>So, I think your options are either run with alsa directly or tweak the
>>jack parameters for more buffers or bigger buffers. Beware that the alsa
>>code in pd ignores xruns completely (that was discussed a while ago in
>>the jack list) while jack deals with them and signals their existence. I
>>think there is now a flag for jack that can emulate that behavior and
>>ignore xruns (can't remember now the name of the flag). 
> 
> 
> My problem isn't with xruns, but instead with pd signalling DIO errors. 
> Even with a period of 512 (running a Delta66), I still get the
> occasional A/D/A sync error from pd.
> 
> One other question - how do I specify 4 inputs/outputs with jack? 
> Changing the options in qjackctl throws an error.  Thanks again!
> 
> Scott
> 
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
> 


-- 
derek holzer ::: http://www.umatic.nl
---Oblique Strategy # 54:
"Do something sudden, destructive and unpredictable"