I spent a day and a half trying different methods without success. I searched the forum but I can't find an answer to my exact problem.
When I used the method "open samples/xxx.wav, 1" and then "readsf~" to open an audio file chosen randomly between different files (xxx being 0 or 1 or 2 etc etc) all worked fine.
But I have to be able to change the speed of the audio file playing, and the "readsf~" doesn't allow it.
I have to mention that my audio files are quite long and I chosed a length limit of 4min50sec (it seems to be the limit for the audio file to play without issue).
As far as I understand, I need to use "soundfiler" to be able to change the speed of an audio file.
This is working fine with one audio file that is loaded when the patch is getting opened.
But as soon as I want to load automatically a different audio file (chosen randomly in a list of audio files), then it won't work.

SCREENSHOT 1 = If I first chose the file and then read it (adding a delay or not between events), the file will not read, it doesn't appear in the array, it doesn't play.

SCREENSHOT 2 = showing that if I don't chose first the file between different files, then it works. Array ok and audio plays.

Is there a solution for what I'm trying to do?
I need to solve SCREENSHOT 1 to be able to develop the patch further.

@KoaN Thank you for posting what you have discovered. It will surely help someone in the future.

In windows you can start 2 instances of Pd.... one for audio and one for midi.... which can help as although the audio settings do affect the midi lag you can set one of the instances to run with a tiny buffer that would cause audio dropouts..... but use that instance purely for midi.
This can be done in other os's too.

The 2 instances can then communicate control rate messages using [netsend] and [netreceive].
A steep learning curve but you seem to be advancing rapidly.

The instances can be opened with a pre determined setup using command line flags.... http://msp.ucsd.edu/Pd_documentation/resources/chapter3.htm#s3.4.1

Here is an example of a batch file that should achieve this.....

start "C:\Users\David\Desktop\Pd Vanilla\pd-0.55-2.msw\pd-0.55-2\bin\pd.exe -noaudio -midiindevice 2 -midioutdevice 2" start midi_patch.pd
start "C:\Users\David\Desktop\Pd Vanilla\pd-0.55-2.msw\pd-0.55-2\bin\pd.exe -r 44100 -asio -nomidi -audioindev 9 -audiooutdev 9 -inchannels 18 -outchannels 22 -audiobuf 2 -blocksize 64 -callback -nosleep" start audio_patch.pd
exit

The paths will be wrong for your computer, so will need to be changed, and the command line flags will be wrong for your sound card, and probably for the midi devices too. For the sound card and midi devices you should first open your patch and open the Media AudioSettings and Media MidiSettings and write down the device numbers and settings for those found on your system as Ps starts up.
Then create an audio patch (-nomidi) and a midi patch (-noaudio) and change the command flags to match your setup for each.

BUT I cannot (so far) get the flags to work in a batch file opening 2 instances (works fine for one instance so it is my batch programming problem).
So copy the code above into a simple text editor like notepad, save it as e.g. "pd_twice.bat" and then edit it to match your Pd binary location and the Pd files you want to load to each instance. Once the 2 instances are open set the audio and the midi for the instances to something like this and do not turn on DSP for the midi instance.......
Keep the batch file with the Pd files you are loading in the same folder.

Of course your settings for the audio and the midi instances will be different..... different devices, different delay for audio.... but the midi instance can have the delay set to 1 (or maybe even 0) as it will not be running any audio.
As @jameslo says above...... in Pd the "Delay" setting is the buffer for communication with the sound card.
David.

@lacuna said:

Don't know about phasor's right inlet, but I guess for more precision on the outside of objects we'd have to use 'Pd double precision'.

Yes, I confirmed that my test patch runs without issue under Pd64. Unfortunately, my real patch doesn't

Also remember @ddw_music different approach than [phasor~]:

I think that "different approach" is a different issue--I'm not multipying its output to index into a large table. I'm just using it as an oscillator/LFO. Are you suggesting that there's a way to build an oscillator with [rpole~] that is as frequency-accurate as [phasor~] but without the single vs double precision issue?

On one sample late: It is [snapshot~] who is early, not [phasor~]:
...
I would call this a bug of [snapshot~] !%§$*(

I don't understand your conclusion about the timing of [snapshot~]. Here's how I would analyze your demonstration patch: the top bang is processed in-between audio blocks. Therefore, [tabplay~] and [fexpr~] run in the following audio block. [snapshot~] is different though, because it's a bridge between control rate and audio rate--like bang, it also runs between audio blocks. Therefore, the best it can do (without having to predict the future) is to return the last sample of the previous audio block. So it's not surprising for [fexpr~] to have to reach back into the previous audio block to get the same value as [snapshot~]. If [snapshot~] were to return the first sample of the following audio block, it couldn't pass that value to control rate code until that audio block's processing is complete. Do you see my point?

Also, I'm not saying [phasor~] is early, I'm just saying its right inlet isn't a mechanism for restoring its state. It's just for what the documentation says it's for: to reset its phase to a given value.

WRT real-time audio, the most important performance factor is: will the next hardware buffer's worth of audio be ready on time?

If we assume a 512 sample hardware buffer and a 48 kHz sample rate, then each hardware buffer takes 10.6666667 ms.

If the audio calculations finish in 1 ms, that's roughly 10% of the available time. If they finish in 5 ms, that's 50%.

RT audio calculations tend to happen in bursts. IIUC (I could be wrong) system CPU monitors are looking for sustained CPU activity, which does not characterize RT audio. So the system monitor might tell you that the system isn't very busy, but the DSP thread might actually be stressed.

For instance, I just ran a bunch of DSP in SuperCollider and it reported about 38% CPU use, but the system task monitor reported 4%. (But htop showed one CPU core with high activity, and the rest mostly idle... so a single CPU usage number that aggregates all the CPU cores can also under-report.)

I think I remember reading here that Pd does its audio calculations outside of the audio driver's callback, and uses the callback only to copy data, meaning that audio subsystems like JACK in Linux might significantly underreport CPU usage. So the whole thing is a bit of a tricky question. I don't know how Purr Data is measuring CPU use.

hjh

@nenleh said:

In an tutorial I have seen that someone marked the checkbox "compute audio" in the main window of PD (first picture) to solve this poblem.
But I do not have this checkbox (second picture).

Ancient tutorial, then. The current "DSP" checkbox is the same as the old "compute audio" box.

What can be the problem?

The console messages that you get after clicking DSP say that it's an audio driver problem: Pd is trying to connect to an Advanced Linux Sound Architecture instance and this is failing.

Linux audio is famously messy. The current best attempt to clean up the mess is Pipewire, so I guess your best option may be to install Pipewire and run pd under its power. If it's me, I'd use the Media menu to choose the JACK backend and then run pd as "pw-jack /path/to/pd-gui" (I think; not at the computer right now, and the path may vary depending on Linux distro).

I have not yet used Pipewire, though, so I couldn't troubleshoot beyond that. Linux audio forums could help more. (Note that Linux audio being chaotic and disorganized isn't Pd's fault -- but once you get the audio subsystem configured, then it works for every app. It's painful only the first time.)

Also, "priority 6 scheduling failed" means that you should add your user to the "audio" group.

hjh

@Pandas As above..... Pd has an input > output delay equal to its block size.
Put something in and it will output 64 samples later.
But the soundcard cannot convert that to analogue instantly... so we add a buffer that gives it time to process the audio before the next block arrives.... MOTU 2-3ms with ASIO... On board soundcard usually 30-80ms.
I see you posted elsewhere on the forum..... https://forum.pdpatchrepo.info/topic/14495/sync-to-external-daw-midi-clock-audio-latency
I don't know those programs and maybe someone else will help.
Sending the audio samples to another program through a port will still not be instantaneous... but should be close unless you are listening to it at the same time.... but even media players will buffer at least 512 samples before they play a stream.

Does QSynth have compensation settings to delay the midi and attempt to match the audio timing?
What is your OS?
As you are communicating with software rather than a DAC you could try reducing the Delay (mSecs) in Pd media settings,,,,,, down to 3, then 2, then 1.. 0 probably not but you never know.... basically until it hangs and then go back to the last setting that worked.
Apply but don't save the settings until you are done.... or Pd might not start or might not let you change them again while it is "stuck" even if you restart it.
There is a fix for that..... I will upload it if that happens..

Running Pd at 96kHz audio rate should I think reduce the 64 sample (Pd internal) block delay.... you could try that too...... I think it should output in half the 48kHz time.

And try this..... it might help....... depends what you are wanting to achieve...... https://forum.pdpatchrepo.info/topic/13125/batch-processing-audio-faster-than-realtime
David.

The amount of input-->output latency comes from the soundcard driver settings, specifically, the hardware buffer size.

"Where does latency come from" is this:

The audio card driver processes blocks of audio. (If it didn't process blocks of audio, then it would have to call into audio apps once per sample. There is no general purpose computer that can handle 40000+ interrupts per second with reliable timing. The only choice is to clump the samples into blocks so that you can do e.g. a few dozen or hundred interrupts per second.)

Audio apps can't start processing a block of input until the entire block is received. Obviously this is at the end of the block's time window. You can't provide audio samples at the beginning of a block for audio which hasn't happened yet.

You can't hear a block of output until it's processed and sent to the driver.

| --- block 1 --- | --- block 2 --- |
| input.......... |                 |
|                \|                 |
|                 \_output......... |

This is true for all audio apps: it isn't a Pd problem. Also Pd's block size cannot reduce latency below the soundcard's latency.

You can't completely get rid of latency, but with system tuning, you can get the hardware buffer down to 5 or 6 ms (sometimes even 2 or 3), which is a/ good enough and b/ as good as it's going to get, on current computers.

hjh

Hello all,

Running 'Pd-0.52-1-really' on a 2021 M1 Macbook Pro. When I need to change my audio preferences (namely my audio output device) in PD, I can select the output I need, but when I click 'Save All Settings' or 'Apply' the following happens:

• 'Audio off' switches to 'Audio on' in the main PD window (the DSP checkbox does not respond, it remains unchecked)
• PD freezes: clicking OK or cancel in the Audio Settings window yields no response, the window will not close via any means. Similarly, if I have a patch open this will also freeze and cannot be closed. I have found I can close the main PD window, but I cannot quit PD- I have to force quit via the finder.

Upon reopening PD it's a gamble as to whether the audio setting I changed has even been remembered. This is extremely frustrating and is rendering the software very unreliable and hard to use (especially as I use it almost exclusively for audio).

Also, if I skip the process of clicking 'Save All Settings' or 'Apply', and just hit 'OK', the audio settings window closes, but the program still freezes in the same way.

Additionally, I'm trying to open a patch that contains a load bang to start DSP, and this will also freeze the program.

Has anyone else experienced this, and can they suggest any solutions? Thanks!

yes, Katja's meter measures 1 sample latency additionally, so real latency is -1 sample.

here are threads of other forums:

https://forum.rme-audio.de/viewtopic.php?id=23459
linking to
https://web.archive.org/web/20160315074034/https://www.presonus.com/community/Learn/The-Truth-About-Digital-Audio-Latency

and an older comparision:
parts 1 2 3:
https://original.dawbench.com/audio-int-lowlatency.htm

https://gearspace.com/board/music-computers/618474-audio-interface-low-latency-performance-data-base.html

@esaruoho Updating the array while recording will probably cause dropouts. Redrawing onto the screen is hungry and unadvisable in Pd.

You can stop and start from the same point..... using a counter and restarting with a [start index(...... message, index being the next sample after where you stopped.
But.
Complicated.

It will probably be easier to stop audio computation when you press the [stop( button..... which will pause the writing to the array.
That will "freeze" audio for that window..... so you will no longer hear any audio that the window generates...... but other windows being unaffected you should be able to organise the patch to still hear what you need from elsewhere.
Put a [switch] object in the window with [tabwrite~] and toggle audio on off with a message..... 1 on.... 0 off.
Then connect [stop( to a 0 message and [resume( to a 1 message to [switch].
It will cause clicks, but you can stop that, while only losing a tiny bit of precision for the stop point, by "ducking" the audio before and after the [switch] operation like this.....

Use the [line~] output to duck the audio to [tabwrite~] so that there are no clicks on the recording as [switch] stops processing..... the audio recording level will be at 0 when processing stops and then fade up from 0 in 5ms when you start again (3ms after audio is turned on fully in the screenshot).
Set the [pipe] value lower if you wish..... 3 might be sufficient with 2 for the message to [line~].

The clicks might not matter at the stop/resume point of course....... and might make it easier to spot the "join" later.
David.