... for basic prototyping, if you don't have any install around. by @cuinjune

purrdata.glitch.me

https://github.com/cuinjune/purr-data

@lacuna said:

The helpfile of soundfiler says:
"If no array name is given, no samples are read but the info is provided anyway."
Not sure if this is actually the case, as I get drop outs occasionally. Does it read the header only?

As Ross Bencina points out in a justifiably famous article, "All sources of audio glitches within your code boil down to doing something that takes longer than the buffer period. ... The main problems I’m concerned with here are with code that runs with unpredictable or un-bounded execution time. That is, you’re unable to predict in advance how long a function or algorithm will take to complete. ... Doing anything that makes your audio code wait for something else in the system would be blocking. This could be acquiring a mutex, ... snip snip..., waiting for data to be read from disk..." (hmmmm).

If [soundfiler] is blocking for filesystem access and it affects the audio thread, then it would explain the glitches. In that case, it might not even need to read a large amount of data -- if the data aren't in the filesystem RAM cache already, spinning the HD to the right speed and pushing the drive head to the right position could take longer than the available time. A SSD might fare better but there are no guarantees. Filesystem access should be treated as time-unbounded and not safe for real-time audio -- even just reading a header.

IOW if my guess is correct about [soundfiler]'s behavior, then it is breaking Bencina's prescriptions for real-time safety = bug. ("Especially if your software is going to be used to perform to a stadium full of fans... you do not want your audio to glitch. Period.")

SC's solution (shunt time-unbounded ops into a queue running in a lower priority thread) is one correct way. There might be others. I just wonder why Pd seems not to be doing that.

hjh

@lacuna said:

Here is another thread with [soundfile_info], - where I tried to get the info running [soundfiler] on a different cpu-thread with [pd~], but it still glitches for me with very long files (why?):

Here, I wonder if it would be feasible for soundfiler to be changed so that it could use a lower priority background thread for filesystem access. There isn't any need, really, for it to lock up the engine while doing time-unbounded things with the filesystem. Soundfiler pops out a message when it's done; I can't see any reason why this must be synchronous -- just load up in the background and the patch continues in response to the output message.

SuperCollider doesn't glitch the audio when manipulating soundfiles because 1/ the audio server pushes expensive ops like file access onto a lower priority thread, running a command queue and 2/ for this topic's initial question, you can query a soundfile's header without loading the contents and this is in a completely separate process from the audio engine.

I'm just wondering if anyone knows whether the blocking behavior of soundfiler is due to a necessary design factor or if it's just because nobody implemented a background thread for it.

(Still wondering why Vanilla can't read the header info only, without loading the whole file?)

Minimal core

hjh

Something that might be obvious to some people here, but wasn't obvious to me --

If you're trying to sample an LFO signal and use this to control video, make sure that the sample rate is an exact multiple of the control block size. This is not the case for 44.1 kHz vs a 64-sample control block (but it is the case for 48 kHz vs 64 samples).

In this patch, it looked like the logic was correct, but the LFO "jumps" about once per second.

ofelia-timing-glitch.mp4

But if I start JACK with a 48 kHz sample rate, then the same patch is perfectly smooth.

Curiously, though, setting the block size to the largest power-of-two factor of 44.1 kHz ([block~ 4 1 1]) doesn't affect the behavior at all. (Fun fact: 44100 = 2*2 * 3*3 * 5*5 * 7*7.)

Probably this affects any similar use of [tabwrite~] but the impact is more dramatic when it's controlling graphics.

Something to be aware of...
hjh

Ok thanks for the clarification. Replacing the [bang~] by a [metro 5} actually removed the glitch. If I go any faster than 5ms it glitches again. Not quite sure yet if this is going to be fast enough but I'll go with that for now anyway.

Hi there...
I'm currently working on a Final Year university project where we have to create a new Creative Music Technology using Pure Data (which we've never used before). My idea consists of using the pix_blob and pix_multiblob to trigger certain outputs. For example, 2 red dots on a card would trigger the 2nd stored chord sequence. To make this more creative and interesting, I want to be able to have one side of the
live video be tasked with detecting colours and triggering chords and the other to be detecting colours and triggering drums. Does anyone know a way of isolating sections of a the video to do this?

@scientificsound It might be that you need to add your user account to the audio group?
But more likely, given that some programs have access to sound and some not, that PulseAudio is getting in the way.
Try removing PulseAudio, and if you are told that it is not found then install it and then remove it........
https://www.element14.com/community/community/raspberry-pi/blog/2019/09/14/asla-audio-glitch-issue-pi-4-fix
A reboot afterwards is probably a good idea.
David.

Hi, I'm building an audio sound engine for a mobile game using libpd and the rjlib library. I want it to be CPU efficient so as to run on lower end android phones too without glitches

My first assumption is that playing back audio is less costly than using synths : is this a fact or am I wrong from the start ?

The idea is to build a flexible sampler with distinct attack, sustain and release parts. I can then load any synth sound I exported from my DAW and play it almost as if it were the original synth (without all the modulations of course). Kind of like the ableton sampler: I could choose the start, the sustain loop portion, and the release part of the sound. That would allow me to add portamento, amplitude, pitch and filter enveloppes, hold notes forever, instantly change the pitch, with no glitches between parts ... It would have to sound like I was playing the original synth preset from my DAW, inside PD !

However this looks a bit trickier than I thought and seems to require a bit of patching. In the end I'm wondering if it's not going to end up costing more resource from the CPU than using a PD synth ?

So before I start building this thing I'm wondering : is it a good idea, or I am missing something here ? And also, does it not already exist ?

I hope I've managed to be somewhat clear, i'd love to hear your feedback !

Cheers
Simon

@zigmhount said:

In general, I still hear quite many clicks and glitches when playing

Sounds like the most likely culprit is setting the delay too low in your Pd audio settings, which will lead to dropouts when the CPU isn't able to keep up with Pd's computation deadlines. I can sometimes push it as low as 6ms on my 2016 Macbook Pro if most parts of my patch are switched off, but sometimes I have to bump the delay up to 25+ms if many modules are working hard simultaneously.

The only time I've used Pd on Linux was on a Raspberry Pi 2, which needed at least 50-100ms (if not more) to run even very basic audio patches. I haven't used Jack, so I can't say whether that could cause any glitching trouble. But an easy first step is to increase your delay & see if that helps.

Another possible source of clicks could be discontinuities in the loop waveforms, which seems likely if you're hearing it when your looper wraps around. You'll need to add windowing, or a short fade in/out anytime a loop starts, stops, wraps, or jumps to a new position. And, you also need to take care when using [tabwrite~], otherwise discontinuities can be recorded into your loop. For example, something like this:

@beep.beep I actually haven't seen [pd~] before, thanks again! Since DSP needs to be running, I'm not sure how I can actually use it (if I had my 64 tracks as [pd~] subprocesses, they would all have to be "DSP on"), but I'll keep it in mind. It might be more efficient than OSC messages between several DSP instances of Pd, but my machine only has 2 cores anyway, so I'm not sure whether there is much more to optimize there (for now - at some point I might very well be using my patch on other computers, and other people may use it).

I'm now in the process of implementing [switch~] in the different subpatches of my track abstraction, so as to shut off [tabwrite~] when playing and shutting off [tabread4~] while recording, let's see how this goes.

In general, I still hear quite many clicks and glitches when playing, when the [phasor~] reaches 1 and jumps to 0, or just randomly in the middle, even when the DSP instance runs in -nogui, without debug or verbose and without printing OSC messages. Increasing the number of frames per period in Jack from 128 to 1024 doesn't really help. Not sure whether this can be a problem of CPU power or sound card, I may try on another computer to figure it out - I'm on a 10-year old laptop using the embedded sound card (funny thing, I also hear tons of clicks and glitches when opening the emoji panel to write this message, so I suppose it really is a hardware shortfall).