Hello community!

My main question is: how to deal with the i/o-errors, pd chronically suffers from?
I get them on many occasions:

• resizing a table
• sending and processing (routing, splitting into packages) messages/lists of mediocre length
• sending/receiving messages from many objects
• updating gui elements

It's a pain in the ass! processing long messages is a quite basic feature for realtime audio.
Of course the I/O-Error comes with an audio click, which is inacceptable in a live situation.
(I am using pd with jack. There is no xrun in jack, by the way)
Fun fact: pd also prints the I/O-Error message if audio processing is switched of.

My impression is, the problem lies in pd's basic design:
Messages and audio processing is being handled in the same single main loop.
So if message processing takes a little longer, audio gets out of sync.
(Of course this can happen easily on message bursts, e.g. if you want to synchroniously control many objects.)
Can anyone confirm this?

What are the common practices to deal with this flaw on the USER SIDE?
Somewhere I read that I should keep audio processing and gui/message processing in seperate patches/pd instances.
However, this is only possible to some degree.
However, how could this be achieved? How can I force the gui patch to use a seperate thread? do I have to run it in a seperate pd instance?

From the PROGRAMMERS ANGLE: are there any efforts to improve pd's design? (e.g. calculate messages and audio processing concurrently, e.g. in sperate threads). Since this flaw has annoyed me since I have started to use pd, and since I have some experience with programming, I would like to offer my help to fix it!
Has this problem been solved in any of pds "forks" yet?
I love pd, but it still has profound issues, in my humble opinion.

@EsGeh You should not be having these problems. At all. Except "resizing a table".
Even that should not cause a problem if it is hidden in a sub-patch and you are not reading from it as you resize.
I can run a 64ch in 64ch out mixer controlled by osc messaging from 64 tablets in Pd, at 3ms latency without a glitch (Extended on Windows7)

Are you running Pd at the same samplerate as your soundcard?
Are you trying for too small a buffer to improve latency?
Have you given Pd root priority (chmod 4755)?

Could you post some more detail..... os, soundcard, Pd version?
Chapter 2.5 ........ https://puredata.info/docs/manuals/pd/x2.htm/?searchterm=i/o error
explains what Pd gets up to, and why it is best to hide unused gui's, and there is more help on that site.

You can run more than one instance of Pd and communicate between them through ports, and that will sprout 2 instances of wish, which spreads the gui load as well. Whether your OS will run them all in the same processor I don't know. Recent OS's should automatically spread them about.

I have had problems trying to control a gui through more than 2 levels of gop.
If you wish to post a problem patch then we can see if it works well on our systems, which might narrow it down.
David.

@whale-av: thats interesting.

Details about my system and configuration:

OS.: arch
pd-version: Pd-0.49.0 ("") compiled 17:22:56 Sep 26 2018
pd config:

audioapi: 5
noaudioin: False
audioindev1: 0 2
audioindevname1: JACK
noaudioout: False
audiooutdev1: 0 2
audiooutdevname1: JACK
audiobuf: 11
rate: 41000
callback: 0
blocksize: 256
midiapi: 0
nomidiin: True
nomidiout: True
path1: /home/samuel/.sgPD
npath: 1
standardpath: 1
verbose: 0
loadlib1: sgCLib/sgScriptLib
loadlib2: sgCLib/sgInputC
loadlib3: zexy
nloadlib: 3
defeatrt: 0
flags: 
zoom: 1
loading: no

sound-server: jackd
jack config:

> jack_control dp
--- get driver parameters (type:isset:default:value)
            device: ALSA device name (str:set:hw:0:hw:0)
           capture: Provide capture ports.  Optionally set device (str:set:none:hw:0)
          playback: Provide playback ports.  Optionally set device (str:set:none:hw:0)
              rate: Sample rate (uint:set:48000:44100)
            period: Frames per period (uint:set:1024:256)
          nperiods: Number of periods of playback latency (uint:set:2:2)
             hwmon: Hardware monitoring, if available (bool:notset:False:False)
           hwmeter: Hardware metering, if available (bool:set:False:False)
            duplex: Provide both capture and playback ports (bool:set:True:True)
          softmode: Soft-mode, no xrun handling (bool:set:False:False)
           monitor: Provide monitor ports for the output (bool:set:False:False)
            dither: Dithering mode (char:set:n:n)
        inchannels: Number of capture channels (defaults to hardware max) (uint:notset:0:0)
       outchannels: Number of playback channels (defaults to hardware max) (uint:notset:0:0)
            shorts: Try 16-bit samples before 32-bit (bool:set:False:False)
     input-latency: Extra input latency (frames) (uint:notset:0:0)
    output-latency: Extra output latency (frames) (uint:notset:0:0)
       midi-driver: ALSA MIDI driver (str:notset:none:none)

root-priority: Hmm. I guess no. I'll try your suggestion, and see if it helps!

Configuration is pretty standard, I guess.

My impression is that certain events in my patch cause some messages being sent to multiple destinations, which causes pd to get out of sync.
It's slightly difficult to isolate the problem(s) into a small example, since I am using my own library of abstractions for parsing/generating recursively structured messages and automatically/dynamically connecting objects. I use this e.g. to let one object track properties of another one. It's nothing too fancy, all just native pd.
The amount and length of messages is still very moderate. It's disappointing to see pd struggle already.
(e.g. a "sample recorder" would record audio and update the "sample" object, by sending a "length" of the recording in ms, which in turn also distributes this message to ~3 "sample player" objects).
I will try to make a small example, that shows the issues I am facing.

Thank you for your help so far!
Any suggestions are welcome

Have you given Pd root priority (chmod 4755)?

why should I do that? this would make pd run as root always right?
pd already runs with realtime priority, as far as I can see:

$ pd -rt &
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackLinuxFutex::Connect name = jack_sem.1000_default_pure_data
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = pure_data refnum = 4
Jack: JackClient::PortRegister ref = 4 name = pure_data:input0 type = 32 bit float mono audio port_index = 7
Jack: JackClient::PortRegister ref = 4 name = pure_data:input1 type = 32 bit float mono audio port_index = 8
Jack: JackClient::PortRegister ref = 4 name = pure_data:output0 type = 32 bit float mono audio port_index = 9
Jack: JackClient::PortRegister ref = 4 name = pure_data:output1 type = 32 bit float mono audio port_index = 10
Jack: JackClient::Activate
Jack: JackPosixThread::StartImp : create non RT thread
Jack: JackPosixThread::ThreadHandler : start
Jack: JackClient::kBufferSizeCallback buffer_size = 256
Jack: JackClient::Init : period = 5804 computation = 100 constraint = 5804
Jack: JackPosixThread::AcquireRealTimeImp priority = 5
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 2
Jack: JackClient::kActivateClient name = pure_data ref = 4 
Jack: JackClient::Connect src = system:capture_1 dst = pure_data:input0
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::Connect src = system:capture_2 dst = pure_data:input1
Jack: JackClient::Connect src = pure_data:output0 dst = system:playback_1
Jack: JackClient::Connect src = pure_data:output1 dst = system:playback_2
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18

$ ps al | grep pd
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000  1212   746  -7   - 259980 183892 -     SLl  pts/0      0:19 pd -rt
0  1000  1214  1212  20   0  58984 24812 -      Sl   pts/0      0:02 wish /usr/lib/pd/tcl//pd-gui.tcl 5401
0  1000  1216  1212  -9   -   2308   796 -      S    pts/0      0:00 /usr/lib/pd/bin/pd-watchdog
0  1000  1311   746  20   0  15064  3088 -      R+   pts/0      0:00 ps al
...

@EsGeh I have seen it recommended by Miller to get audio working correctly on a RPI...... just applied to /bin/pd
You can always change it back if it doesn't help.
4755 user can read write and execute, group and others cannot write.
I am no Linux expert, but you have maybe provided enough info for @EEight to spot something.
David.

I have come to the conclusion, that sending many messages to several destinations can easily cause audio clicks.
(Same for resizing, normalizing and clearing tables, and updating many GUI elements.)
It seems crucial to optimize patches to keep the the number and length of messages minimal at all costs.
Maybe it helps to implement more sophisticated message parsing/processing in C and include as an "external" - I am going to try that.

Chapter 2.5 ........ https://puredata.info/docs/manuals/pd/x2.htm/?searchterm=i/o error
explains what Pd gets up to, and why it is best to hide unused gui's, and there is more help on that site.

The article is interesting indeed! Seems like pd makes strong guarantees about the semantics of message passing. There seems to be no easy way of solving the problem of message bursts causing audio clicks while maintaining nice predictable semantics...

I come from here: https://forum.pdpatchrepo.info/topic/9461/record-audio-of-any-length-into-array/8
Then, searching more about sound clicks and interruptions I've found this thread so I will continue here.

I'm dealing with the exact same problem as you, especially when resizing tables, which is crucial for dealing with samples and loops in realtime audio processing applications like you said. As far as I know, Pure data was designed in a way that array modifications and object calculations are done in the same thread the audio is flowing, so it's impossible to separate them and audio will be always interrupted. So, after looking for pure data distributions and externals, I've found something that maybe solve part of this problem, the sndfiler external, which is included in the last pd-l2ork distribution:

https://github.com/pd-l2ork/pd/tree/master/externals/tb/sndfiler

FEATURES:

• threaded reading of multichannel soundfiles into arrays
• threaded resize of arrays

I've installed the latest pd-l2ork distribution in windows and the sndfiler isn't installed by default, but it appears in the source code, so I will have to try building it from the source code if nobody has the built external. It also needs libsndfile and libvorbisfile and threadlib external in pd, a little bit complicated but may solve the problem.

For the GUI updating problem, you may solve it by separating the main GUI and the sound processing in differents patches. I've been doing this separation since I started using pd and never run into dsp problems.

Has this problem been solved in any of pds "forks" yet?

In Purr Data we've addressed a few of the GUI updating problems:

• data structures use Pd's extant guiqueue system to keep from sending unnecessary graphical update messages to the GUI. I noticed that the pacdata game (pacman using data structures) runs smoothly on Purr Data for this reason. It probably still uses lots of CPU and would cause dropouts during complex audio computation, though.
• data structure array elements can react to mouse events very efficiently. This is because they don't constantly recalculate their bounding rectangle on every single mouse motion like everything else in Pd does.
• moving a selection of objects in Purr Data only requires a single message between core and GUI, whereas in Pd it requires a separate message for each object
• complex data structures cache their bound rectangle
• some small optimizations for iemgui messages that get sent to the GUI
• text box edition (e.g., typing stuff inside an object/message box) happens completely inside the GUI. So you can paste an enormous amount of text and it won't get sent Pd until you're ready to instantiate the object.

One of the biggest pains for users is the constant polling of bounding rectangles for objects-- it happens any time you move the mouse in a patch window. Someone made an introductory patch to solve this but it's not complete so it hasn't been merged.

I've got an idea about how to move all the logic into the GUI. Still, it's a big undertaking and I'm not sure I have sufficient time to properly implement atm. And notice that all that hard work would only solve 1/4 of your issues. Dropouts from resizing a table are a separate issue. Message-passing overhead is a separate issue, too.

@jancsika I've just realized that you are the creator of purr-data right? In that case, thank you for making such amazing distribution, I hope I could help you with your distribution to solve the problems that you pointed out, but I don't think I have the sufficient programming knowledge, that's one of the reasons I started to use puredata instead of c frameworks

I have one question about the libraries in purr data, it has to do with this topic too: I've seen that the sndfiler library is included in the source code of purr data, but I can't see it in the windows and raspbian built 2.8.0 installations package, is there a reason why sndfiler is not installed even if it's included in the source code? I want to use the sndfiler to resize arrays without interrupting the dsp, which is one of the features of this library but I don't know how to do it, I can't find the built library (the repository link is down) and I don't know how to build it with the source code.

@JackPD Ok, looking at sndfiler. Let me see if I understand it correctly.

Take the following test patch:

[table foo 128]

[nbx]
|
[; A bang; B resize foo $1; C bang(

[receive B]
|
[sndfiler]
|
[bang]
|
[send SNDFILER_OUT]

[r A] [r SNDFILER_OUT]
|     |
[timer]
|
[print first]

[r C]
|
[print last]

Is it true that I would get output printed in the order "last" then "first"? If so then sndfiler breaks Pd's depth-first message passing rule.

Is it true that [timer] here will output different values depending on the size of the float provided to [nbx]? If so then [sndfiler] breaks Pd's deterministic scheduling rule.

Also, it appears a "resize" message with no arguments would crash Pd. That's a bit alarming given that I just happened upon it while scrolling through the source. Threading issues are extremely difficult to debug so I'm a bit cautious about exploring much further. (Also there's a threading wrapper library dependency by yet another author...)

Just for a thought-experiment: imagine a set of "delay" externals that try to do computation on a separate thread in the time allotted:

[resize foo 256(
|
[sndfiler 50]

In this case "50" would mean to delay output for 50 milliseconds from the time the object receives an input. So you send the resize message, sndfiler does the work in a separate thread, and after 50ms the object gets a callback to send output.

Now, if the thread has finished its work the output would be sent deterministically. If not the object would block until the thread has finished, send the output, then display an error to the console that it missed a deadline.

That's basically just mapping Pd's system scheduling to control objects. I think that would be a very clunky design that would be hard for users to maintain and reason about. But it's still preferable to breaking determinism as sndfiler apparently does.

Btw-- even after sndfiler finishes its threaded array resizing, it still must rebuild the dsp graph for the reasons I mentioned in my last message. So for patches with lots of signal objects you'd probably still generate dropouts.

Hm... here's an idea:

1. Require every class that deals with garrays to have a "set" method
2. Require the "set" method of these classes to bind the object to a symbol that concatenates the array name with something like "_setter". So [set foo(--[tabread] would bind that object to symbol "foo_setter"
3. When array "foo" gets resized, send a message "set foo" to "foo_setter"

Now every table-related object that uses array "foo" will have an updated reference to the newly resized array before the next dsp tick. This is because when you send a message to a receiver symbol in Pd it will dispatch the message to every object that shares this name.

On the other hand, the "set" methods of table-related classes in Pd weren't designed to be realtime safe. For example, some resize values may trigger an runtime error condition that requires rebuilding the graph. I guess the algorithm above could call some kind of "slim-lined" version of "set" that does size-based checks but excludes things like array name lookups, etc. But that would require splitting out every single "set" into a set of two methods.

A combination of that and the delay-based sndfiler could get you array resizing without dropouts. But that's a very clunky interface which is difficult to debug for a lot of work upfront just to get it running.

@jancsika I see, so it's basically "cheating" the system.., I can't test the patches that you wrote because I don't have the sndfiler library, I can't find it and the original repository link is down, if you have the sndfiler.dll, could you upload it? I don't know how to build it from the src...

Thanks

@JackPD It doesn't actually ship with Purr Data. We aren't currently building any of the libraries that weren't originally getting built under Pd-extended.

But I can see later if that lib will build.

@jancsika This is what I have inside the folder externals of the source code. The folder is named tb tb.rar and the sndfiler is inside it. Honestly, I have no idea of how to build the external from those files.

Thanks for your help Jancsika

So the "threadlib" dependency of sndfiler has some core functions full of assembly code. Files are date 2005, meaning they contain no arm assembly and therefore won't compile on my Chromebook.

If I get a chance I'll try compiling it under windows using msys2.

@jancsika I already have threadlib installed and running in pure data, unlike sndfiler this one is still avalaible at http://grh.mur.at/software/threadlib.html

sndfiler is the one that I can't find or build. I will try to build it but I'm not really experienced in this topic.

@JackPD Here's a zip with sndfiler and a working threadlib, with help patches for each...sndfiler.zip

You're going to have to do the following:

1. Put that "threadlib.dll" in Program Files\Purr Data\bin (or Program Files (x86)\Purr Data\bin if you're on an amd_64 machine). Windows will ask you for admin privileges.
2. Unzip the folder somewhere.
3. Open sndfiler-help.pd in Purr Data.
4. Test out the object there, or save other test patches to the same folder where sndfiler.dll is located.

You can also set your path/lib preferences accordingly, use declare, etc. But the method I outlined above should be the most straightforward.

And now I can confirm-- [resize(---[soundfiler] will indeed crash Purr Data! Make sure you always provide the array name and new size as arguments for that message. However, I can also confirm that [resize array1 440(---[sndfiler] will indeed resize array1 to the correct size. So you should be able to at least test it out.

@jancsika Thanks for building the sndfiler library, I had no idea on how to do it... Anyways, as you have said, it crashes pure data instantly, not only that, it also crashes ASIO in windows, forcing a restart to make the soundcard work again.

Confirming that sndfiler crashes pure data like crazy and doesn't work in any possible way. I discovered something interesting. If I put the array in another patch and I don't open the graphics of it, the [resize( message doesn't affect to the dsp performance, so now I can record arrays and resize them at the same time whatever the duration of the recording is. It's a huge improvement to my application, Another thing that I would like to do is to actually see the waveform of the recorded array, but having opened the array graphic interrupts the dsp a lot..., But at least the audio functionality is working, so I'm ok for the moment...

It will be interesting to see how large your patch can get before rebuilding the dsp graph (which happens after "resize") starts to cause dropouts...

@jancsika said:

It will be interesting to see how large your patch can get before rebuilding the dsp graph (which happens after "resize") starts to cause dropouts...

It doesn´t get too big, a few seconds from size 0 an it already starts to cause drops on the DSP, I made a little recording of it (samplerate 48000 and updates the array every second):
https://s1.webmshare.com/mYq7e.webm

If I hide the graph, I can record forever and the dsp runs perfect from start to finish. It has to do with the graphical update of the array, which I think is very hard to hold along the dsp the way pure data is made. I love pure data for its simplicity and ease of use, but it doesn´t deal with threading very well, we´ll see if this is solved in the future...

@JackPD said:

If I hide the graph, I can record forever and the dsp runs perfect from start to finish.

What I'm asking is this-- how many signal objects can you add to your patch before you start getting dropouts on every single resize of your array?

You can test it like this:

1. add an [osc~] somewhere in your patch or on a subpatch. Then send your resize messages to [sndfiler] and see if you get a dropout.
2. If no dropouts happen, duplicate the [osc~] so that you have two of them. Then send your resize messages to [sndfiler] and see if you get a dropout.
3. If no dropouts happen, select the two [osc~] objects and duplicate those so you have four of them. Then send your resize messages to [sndfiler] and see if you get a dropout.
4. If no dropouts happen, select the four [osc~] objects and duplicate those so you have eight of them Then send your resize messages to [sndfiler] and see if you get a dropout.

etc.

Keep selecting and duplicating these [osc~] objects until you begin to get dropouts when sending the resize message to [sndfiler]. Then tell me how many [osc~] objects you have in your patch.

@jancsika With only one osc the dsp drops out directly, It doesn't matter how many osc objects are present, the update of the graphical array freezes the dsp everytime it resizes independently of the number of audio sources and active objects.

Sndfiler crashes my pure data in every situation I've tried, so I can't use it.

I think the solution has to be solved by it's core, maybe in future versions the engine can treat threads better and separate more operations like resizing arrays from the dsp threads, but since I'm not a developer I don't know about this.