View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007787 | ardour | bugs | public | 2019-08-13 16:18 | 2019-08-24 15:17 |
Reporter | kjetil | Assigned To | x42 | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | duplicate | ||
Platform | Windows 10 | OS | Windows | OS Version | 10 |
Product Version | 5.12 | ||||
Summary | 0007787: GUI freeze when changing parameters in the "a-High/Low pass Filter" plugin. Windows 10 + GeForce | ||||
Description | (see "Summary" and "Steps To Reproduce") | ||||
Steps To Reproduce | 1. Install Windows 10 v1903 2. Install Nvidia Geforece GT 1030 GFX card, driver version 431.60 3. Start Ardour 5.12 4. Create an "a-High/Low-Pass Filter" plugin. 5. Open GUI for that plugin. 6. Make sure "Plugin analysis" is visible. 8. GUI starts freezing around 5 seconds, and very often, if you move the sliders. | ||||
Additional Information | It does not happen on Linux with Intel GFX card. | ||||
Tags | No tags attached. | ||||
|
I've tested all the other "a-*" plugins now, and it only happens for the "a-High/Low-Pass Filter" plugin. |
|
Making sure v-sync is turned on in 3d settings for the GFX card made no difference. |
|
Found a workaround. It's not freezing if I comment out this line: siz = lpf_chunk from dsp_run. Maybe lots of exceptions are thrown in the inner loop for some reason? Just commenting out the call to self:queue_draw makes no difference, so it seems to be the dsp function itself that's causing the freeze. The sound seems fine though, but maybe there's some magic in ardour that makes sure the audio graph runs properly even when a lua dsp function fails? |
|
Alas, no magic. Also no exceptions are thrown.. if there was any, the Lua-plugin would be bypassed. Commenting out that line prevents the plugin from interpolating at 64fpp when a parameter changes. If you show the plugin-analysis in the GUI, Ardour creates a 2nd instance of the plugin which runs in the GUI thread, non-realtime, and measures the impulse response, using a rather large block-size (8k). I suppose that can be CPU intense, but I don't yet see how graphics driver could have any influence on this. |
|
Two things changed when this started happening. The first change was changing graphics card from amd to nvida. The second change was upgrading windws 10, from a build around a year ago, to 1093. It's not my computer, so I don't want to change back the graphics card, and I certainly don't want to downgrade the operating system. The behavior is also a little bit peculiar: 1. Start moving one of the sliders back and forth. 2. For around 10 seconds, everything works fine. 3. Then the GUI starts freezing. It takes around 5 seconds after stopping to move the slider until the GUI unfreezes. 4. As soon as I move the slider again, the GUI freezes for around 5 seconds. The strange thing is the first 10 seconds where everything works. Could it be a buffer of some kind that is filled up? Maybe denormals aren't handled the same way in the GUI thread, and that the windows upgrade somehow changed the denormal behavior? (I think it's an AMD Phenom II processor) |
|
Just tried it again, and I have a feeling about what might be happening. First of all, the initial 10 seconds is actually more like 3 seconds. When I look at the plugin analyzer, the graphics is very slow to update. Maybe 5 times per second. I think what might be happening is simply that the GUI system buffers up more events than 'dsp_run' is able to handle. This change in behavior could be caused by a change in how Windows handle OS events, making the operating system upgrade the cause of the change in behavior, and not the change of gfx card. |
|
Oh, and now I see the exact same behavior on my Linux computer (a different computer) which has intel card and intel cpu. Don't know why I didn't see it the last time I tried... |
|
re "When I look at the plugin analyzer, the graphics is very slow to update. Maybe 5 times per second." That is expected behavior. The FFT window size is sample-rate / 8192. So at 48k it's 5.38 Hz. That's independent of graphics card, and plugin, also independent of "lpf_chunk". |
|
I cannot reproduce the UI freezing. (also note that older versions, used a smaller buffersize, coarser but much more rapid analysis). |
|
I nearly got RSI moving a control forth and back, trying to stall the UI :) So now I've opted to use automation. Feeding white noise into the input. The GUI updates smoothly and the analysis at about 5Hz (Linux, Intel/Thinkpad, Ardour-6.0-pre0-2244-gab62c8a926) |
|
I can't seem to attach a 2.4MB video here, so http://robin.linuxaudio.org/tmp/a-hplp.mp4 Is this similar on your system? a-eq behaves likewise. |
|
Continued at https://tracker.ardour.org/view.php?id=7795 |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-08-13 16:18 | kjetil | New Issue | |
2019-08-13 16:32 | kjetil | Note Added: 0020722 | |
2019-08-13 16:32 | kjetil | Note Added: 0020723 | |
2019-08-14 10:20 | kjetil | Note Added: 0020724 | |
2019-08-24 02:20 | x42 | Note Added: 0020735 | |
2019-08-24 11:23 | kjetil | Note Added: 0020737 | |
2019-08-24 11:41 | kjetil | Note Added: 0020738 | |
2019-08-24 11:54 | kjetil | Note Added: 0020739 | |
2019-08-24 12:03 | kjetil | Issue cloned: 0007792 | |
2019-08-24 12:30 | kjetil | Issue cloned: 0007793 | |
2019-08-24 13:24 | kjetil | Issue cloned: 0007794 | |
2019-08-24 13:45 | x42 | Note Added: 0020748 | |
2019-08-24 13:51 | kjetil | Issue cloned: 0007795 | |
2019-08-24 13:51 | x42 | Note Added: 0020749 | |
2019-08-24 13:55 | x42 | Note Added: 0020750 | |
2019-08-24 13:58 | x42 | Note Added: 0020751 | |
2019-08-24 13:59 | x42 | Note Edited: 0020751 | |
2019-08-24 14:00 | x42 | Relationship added | has duplicate 0007795 |
2019-08-24 15:17 | x42 | Assigned To | => x42 |
2019-08-24 15:17 | x42 | Status | new => closed |
2019-08-24 15:17 | x42 | Resolution | open => duplicate |
2019-08-24 15:17 | x42 | Note Added: 0020754 | |
2019-08-24 15:17 | x42 | Relationship replaced | duplicate of 0007795 |