Until this fateful day, i didn't know what the DIO error button did. Today, though, it turned red and scared the bejeezus out of me. This has never happened before. I did recompile my kernel, but I only added usb-storage to my old .config file. I'm runnig debian 2.6.23.1 with the rt-11 patch. I start jack with qjackctl. I tend to run pd and jack as root, because I'm unclear as to how else is can use the RT funcionality.

The error message says A/D/A sync. I have a pretty good idea what this means, but how do I fix it?

Bump...

I am having the same problem. When I send audio out from PD using Jack, I get approx. 3 to 6 DIO errors per second; all A/D/A sync errors. Needless to say, the audio comes out sounding like clipped garbage. There is no problem using ALSA directly, but doing so means that only PD gets to use the sound card. If anyone else has some experience with this, I'd really appreciate the advice.

Running ubuntustudio 7.10 (gutsy)
with Gnome 2.20.1 / Linux Kernel 2.6.22-14-rt (real time )

Buffer adjustment. Increasing the frames number will usually solve this (at the expense of some more latency)

Tried increasing the buffer size, but I couldn't go higher than 1024 per period without jack crashing. I doubled the number of frames per period, 8 is the highest I can go without jack hanging up. And I'm still getting A/D/A sync errors every couple of milliseconds. Jack runs fine for me, I get 0 XRUNS at much lower latency settings. All of the DIO errors are on the PD side. I do have GEM, Zexy, and all four iemlibs loaded; could that be slowing things down? I have also tried running both PD and Jack as root, but that didn't help. The errors appear even without a patch open, and the CPU load is never greater than 4%. I am using PD 40-2, vanilla, which came packaged with ubuntustudio. I have built and installed all externals manually. Sorry this is so long winded, I appreciate your help

I too have gotten 0 overruns at higher demand. I've used ardour with 8 channels i/o with much lower latency. Is there perhaps a startup flag we should use for realtime.

On a related topic, I've been meaning to initiate a general discussion about low-latency and Pd. Specifically; does anyone have experience with either PAM or LSM on a modern kernel? As I understand it, the lsm patch is deprecated, and PAM is the recommended method. How does one go about using PAM?

I haven't been keeping up to date with kernel developments. What is PAM? (not pluggable auth I assume?)

When I tried the latest 64studio Pd ran like shit off a shovel, like a hardware device with a few milliseconds latency. No idea what realtime kernel setup that has but it's very fast.

I've done pretty good with my G3 so far. PD seems to be the worst off for some reason.

I did a little digging, There are a few startup flags which I am going to experiment with, that set PD's buffer size, and block size. My guess is that Pd's settings should match those of Jack, the problem is I have no idea how to set that up, This is copied straight from the Pd help file; the complete list can be found by entering " pd -help " into the terminal.

-audiobuf <n> -- specify size of audio buffer in msec
-blocksize <n> -- specify audio I/O block size in sample frames

Jack's buffer arguments are:
Frames/period, which are in powers of 2, ie 16, 32, 64, .... 4096
and periods/ buffer.

I have no idea how these parameters translate to PD's, but I am going to try experimenting with different settings.

addendum: running Pd with the -nrt (no realtime) flag I observed a minimal decrease in the rate of error appearances.

Looked into PAM a little, the file /etc/security/limits.conf allows you to set limits for users and groups. the first column in the group, the second the type of limit, third = item and lastly value.

@realtime - rtprio 90

@realtime - memlock 512000

@realtime - nice -19

Any luck in getting PD and Jack to vibe on samplesize and such? Seems like we should be riding on the shoulders of giants here. Doesn't anybody have a working -rt setup?

This is the uncommented contents of my limits.conf file:

@audio - rtprio 99
@audio - memlock 512000

I am curious; @audio, I presume is a group. given that my kernel is supposed to be a realtime kernel geared towards audio and video, I am assuming that a realtime priority (rtprio ?) of 99 is the highest possible priority. Forgive my ignorance, but all of this stuff is kind of new to me.

School work has prevented me from further experimentation (it is very easy to lose hours troubleshooting as I am sure you have experienced . I'll probably be messing around with this more, a little later in the week. In the mean time, I am gonna test out the pure:dyne operating system; It is designed around PD, and boots from a live CD.

@audio is a group. You could add permissions for a user as well, just leave off the @ and stick in your username. Additionally you can use an astereri* to apply it universally. I'm determined to get this working. I've put a question out in the linux-audio-user group. Which kernel are you currently using? Which patch? I'm assuming that the patch o use would be the one from kernel.org.

Also, I've read that it helps to change the scheduling on some (softirq-*, your soundcard, etc) threads to 99 using # chrt.

It would be very useful if this gets written up for the pdwiki or Hardoffs practical guide once you work it out for Ubuntu.

Believe me Obi, once I get this worked out, everyone will know about it. I have noticed a serious lack of congruity in the info that is out there regarding realtime audio systems. I would be more than happy to share my results.

Thanks for the info, I think it is the 2.22.6-14 kernel, with Ingo molnar's realtime preemption patch, -VP-2.6.9-rc4-mm1-U0. At least is what it says on the Ubuntu website. I'll try giving my username realtime priority, and see if that makes a difference. Will definately post whatever steps lead to a successful result.

Great News,
I got PD working with 5ms latency. Here's my settings, I'll post more when I'm done playing~

$ /usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p128 -n2 -s
$ pd -jack -rt -audiobuf 5 -blocksize 128 -r 48000

you could try compiling ALSA.