Replies: 6 comments 5 replies
-
|
Thank You Andreas :) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much also Andreas, thumbs up |
Beta Was this translation helpful? Give feedback.
-
|
Hi If i have a bunch of read errors next to soome plugin chains (and these causes errors, pops at offline render) what should I do, where should I look for the errors reason? |
Beta Was this translation helpful? Give feedback.
-
|
Read errors should only occur with realtime mode enabled and are caused by timeouts. (You should disable the RT mode before bouncing.) To analyse those chains, disable the RT mode and check the plugin logfile for performance messages like: [19:09:13.098|client|7fd9c38695e0] process block took 34.4325ms (88b7487c-3179-4ffc-82d3-e5cd7d649018) The message tells you, that the audio processing thread had to wait 34ms for the data to come back and that reading the data (line with pb_read) took up most of that time. Now you can check the server log. On the server you can simply grep for the tracing ID in the first row (88b7487c-3179-4ffc-82d3-e5cd7d649018). Open a terminal window on the server and run: # ON MACOS
cd Library/Logs/AudioGridder
# If you have sandboxing turned off
grep 88b7487c-3179-4ffc-82d3-e5cd7d649018 Server/*.log
# If you have sandboxing enabled
grep 88b7487c-3179-4ffc-82d3-e5cd7d649018 Sandbox*/*.log
# ON WINDOWS (open a powershell prompt)
cd C:\Users\<username>\AppData\Roaming\AudioGridder
# If you have sandboxing turned off
Select-String -Path Server\*.log -Pattern 88b7487c-3179-4ffc-82d3-e5cd7d649018
# If you have sandboxing enabled
Select-String -Path Sandbox*\*.log -Pattern 88b7487c-3179-4ffc-82d3-e5cd7d649018This might return a logfile containing the ID. The server entry might look like this: [11:33:24.444|worker|7fb04aac77a8] process audio took 49.4702ms (ecc04676-6b6b-418f-b5ec-90a126df986d) Note: This record does not match the plugin record I was showing before, it is just an example. In the example you see that VIRIDIAN is using most of the processing time. In my case I did non find a matching record, because the problem was on my local machine. Too many apps were running which was causing random latency spikes on my network interface. I will put this as a howto to the homepage. |
Beta Was this translation helpful? Give feedback.
-
|
thank you |
Beta Was this translation helpful? Give feedback.
-
|
Do you have logging turned off? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Usually it is turned off, but for this case I turned on also at server and in the plugin too |
Beta Was this translation helpful? Give feedback.
-
|
Hello, |
Beta Was this translation helpful? Give feedback.
-
|
Hi Maybe it was discussed before, and I di not search enough... cable connection: It means as ag used local mode the communication speed is depends on the outgoing main port's speed? |
Beta Was this translation helpful? Give feedback.
-
|
I can only guess that wifi is causing some overall overhead. In local mode AG is avoiding the network interfaces and uses so called unix domain sockets. You could check the plugin logfile to see what "endpoint" the plugin is connecting to. |
Beta Was this translation helpful? Give feedback.
-
|
Any progress on the next version? Robert |
Beta Was this translation helpful? Give feedback.
-
Major Changes from Version 1.1
Please refer to https://audiogridder.com/latest-releases/ for the full changelog.
Changes from the last pre-release
GENERAL
PLUGIN
SERVER
All downloads are available at https://audiogridder.com/download/.
This discussion was created from the release Release 1.2.0.
Beta Was this translation helpful? Give feedback.
All reactions