#11 Audio crackles during gain parameter changes; GUI is suspect

[Jesse Lang]

Hi.

First, please accept my gratitude for a very useful application. Thank you.

That said, I've got guitarix (latest git as of 9/9/13) running on an Intel P4 Mobile 1.8Ghz notebook with 1G RAM. Not the fastest hardware, but in my mind, certainly adequate for the application domain.

I'd be running on a Raspberry Pi, but I'm having problems with my chosen USB audio interface on the Pi hardware. That is another story. :-)

This notebook is running Debian Wheezy. The issue I'm about to describe exists in the Debian package of guitarix (0.22.4-1) as well, but it seems more frequent with the latest git.

When using my MIDI foot controller's expression pedal to change the pre and post gain settings, occasionally, the audio will break into static for a split second. With the latest git, I noticed that the server and the GUI client had been abstracted (hurray!), so I decided to see if that offered a different result. The server (guitarix -N) did not exhibit the issue. So I figured I would try the GUI client with the server, since I use Live Mode. With the GUI client running, the issue presented.

Using top to monitor the processes, I could clearly see it was the GUI client process that increased substantially in CPU usage when the expression pedal was in consistent use. The server process stayed around 25%-30%, and the GUI process went from 20% to the 50%-60% range.

Also, I will mention that in Live Mode on latest git, the control parameter meters don't respond as smoothly to value changes as they do in the Debian package.

I would appreciate any help you could offer in troubleshooting and resolving these items.

Thank you!

[Andreas Degert]

2013/9/10 Jesse Lang jesselang@users.sf.net

---

• [bugs:#11] http://sourceforge.net/p/guitarix/bugs/11/ Audio crackles
  during gain parameter changes; GUI is suspect*

Status: open
Created: Tue Sep 10, 2013 06:16 AM UTC by Jesse Lang
Last Updated: Tue Sep 10, 2013 06:16 AM UTC
Owner: nobody

Hi.

First, please accept my gratitude for a very useful application. Thank you.

That said, I've got guitarix (latest git as of 9/9/13) running on an Intel
P4 Mobile 1.8Ghz notebook with 1G RAM. Not the fastest hardware, but in my
mind, certainly adequate for the application domain.

I'd be running on a Raspberry Pi, but I'm having problems with my chosen
USB audio interface on the Pi hardware. That is another story. :-)

This notebook is running Debian Wheezy. The issue I'm about to describe
exists in the Debian package of guitarix (0.22.4-1) as well, but it seems
more frequent with the latest git.

When using my MIDI foot controller's expression pedal to change the pre
and post gain settings, occasionally, the audio will break into static for
a split second.

This sounds like you are getting jackd xruns, are there messages about
xruns in the Guitarix log window? (You can also check the qjackctl display
or direct jackd output).

With the latest git, I noticed that the server and the GUI client had been
abstracted (hurray!), so I decided to see if that offered a different
result. The server (guitarix -N) did not exhibit the issue. So I figured I
would try the GUI client with the server, since I use Live Mode. With the
GUI client running, the issue presented.

Using top to monitor the processes, I could clearly see it was the GUI
client process that increased substantially in CPU usage when the
expression pedal was in consistent use. The server process stayed around
25%-30%, and the GUI process went from 20% to the 50%-60% range.

The processor load produced by the GUI should not cause xruns
(independently of if its's running in the same process or a different
process) because the audio threads are scheduled with realtime priority. Do
you still have xruns when you minimize the GUI so that no screen updates
happen? What I suspect is that the xruns might happen due to the video
driver / hardware blocking the processor for long times. Then you would
also get xruns If you use other audio programs like Ardour.

Also, I will mention that in Live Mode on latest git, the control parameter

meters don't respond as smoothly to value changes as they do in the Debian
package.

Is there a delay in responding or is it inexact or stepping response?

would appreciate any help you could offer in troubleshooting and resolving
these items.

Since I'm in holidays with only occasional internet access I might not be
able to answer for some days

Thank you!

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/guitarix/bugs/11/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Jesse Lang]

This sounds like you are getting jackd xruns, are there messages about
xruns in the Guitarix log window? (You can also check the qjackctl display
or direct jackd output).

I forgot to explicitly mention this. There were no jackd xruns. The status icon was grey and I reviewed the guitarix log to make sure there weren't any xruns.

Is there a delay in responding or is it inexact or stepping response?

I would say a little of both. The stepping response would be more noticeable. I'm pointing it out more as a possible symptom of the issue than as an issue itself.

Since I'm in holidays with only occasional internet access I might not be
able to answer for some days

Understood. I appreciate your help whenever you are able to offer it.

[Andreas Degert]

2013/9/10 Jesse Lang jesselang@users.sf.net

This sounds like you are getting jackd xruns, are there messages about
xruns in the Guitarix log window? (You can also check the qjackctl display
or direct jackd output).

I forgot to explicitly mention this. There were no jackd xruns. The status
icon was grey and I reviewed the guitarix log to make sure there weren't
any xruns.

There might be xruns even if jackd doesn't report anything. I've made the
experience that you can have such noise on some systems with jackd v1 when
the RT load goes over 50 %. Especially with embedded systems I've made the
experience that you can have dropped packages in the USB system which lead
to crackling (without any report from the USB driver).

Did you check if it happens when the GUI is running in a separate process
and is minimized? Then both processes are very much decoupled, and apart
from system load and more/less work for the video driver there should not
be any difference between minimized / not minimized (means that if there is
no noise in the minimized case would doubt it's a Guitarix bug). What
happens if you don't use the hardware pedal but something like vkeybd to
change the MIDI controller values? Btw. there are Parameters (like the tone
controls in the cabinet unit) which definitely make noise when they are
changed (avoiding that would be computationally more expensive).

Is there a delay in responding or is it inexact or stepping response?

I would say a little of both. The stepping response would be more
noticeable. I'm pointing it out more as a possible symptom of the issue
than as an issue itself.

I'll check the MIDI controller behavior when I'm back home again (two or
three weeks...)

cheers
Andreas

[brummer]

Hi

I've checked it on my box, with a bit different results.
It is possible to produce high CPU usage in the GUI thread when you move continues a controller, that goes up to 100% CPU in use. But, here it have never a influence on the sound. The GUI thread runs with a slightly lower priority then the engine, therefore the GUI thread have to wait/stop before the engine thread stutter. Which priority have you set for jack?

However, we could reduce the CPU usage of the GUI thread by delay the drawing of the controllers a bit, experimenting here shows that a draw frequency of 25hz is more then enough and reduce the CPU usage of the GUI thread about 50% when you move a controller continually fast. Otherwise it wouldn't influence the overall performance.

@Andreas lets talk about it when you be back.
greets
hermann

[Jesse Lang]

Which priority have you set for jack?

-P70

However, we could reduce the CPU usage of the GUI thread by delay the drawing of the controllers a bit, experimenting here shows that a draw frequency of 25hz is more then enough and reduce the CPU usage of the GUI thread about 50% when you move a controller continually fast. Otherwise it wouldn't influence the overall performance.

This matches my thoughts on this. As I mentioned, this happens both in the normal mode as well as live mode.

Do you have a patch I could apply to try such a change and report back on?

Thanks much!

[brummer]

Okay, I've attached it here,
it's a test-case, and need to implement in a better form, if it solve the issue. Basically it's a timeout(1.9ms) for the gtk main loop any 2 ms, and a other timeout(40ms per draw operation) when the controller get redrawn,

greets
hermann

EDIT: remove patch because it cause unwonted side effects.

[Jesse Lang]

Sorry to hear the patch was taken down. I was just going to grab and build it so I could report back.

Is it worth me still trying the patch and if so, could you e-mail it directly to me?

If not, what are next steps? Thanks!

[brummer]

No, it doesn't make sense to test the patch, as it could lead to exactly the opposite result. We need to find a other way to reduce the controller redraw when it get constantly moved. But, as I already pointed out, I cant reproduce the crackle in the audio, even when my system have 100% CPU in use, the audio engine runs absolutely stable. So I suspect there is a other issue as well in your setup. Could you tell us which graphic driver you have in use? And which desktop environment? And which distribution? I guess you use a self build guitarix version, have you used the --optimization flag with configure? If not, please rebuild it with this flag and report if it helps against the crackle.
I will think in the meantime about a better way to implement a redraw reduce routine into the chain.

greets
hermann

[Jesse Lang]

I'm using the radeon driver with AIGLX which uses dri2. My desktop is openbox 3.5.0-7, and I'm on Debian Wheezy. I am using the git version of guitarix, and did re-build with ./waf configure --optimization. It didn't seem to help with the crackle. I did try minimizing the display so the UI didn't have to redraw. The crackle still exists. So perhaps it does have to do with the MIDI controller and overruns that aren't reported.

I had been able to go back and forth between the Debian packaged version and git version, keeping my presets intact. But since updating from git a couple days ago and rebuilding, my presets are no longer being read by either version. Is there something I can do to restore them? The file still exists in ~/.config/guitarix/banks/. Maybe it got corrupted somehow?

[Jesse Lang]

Just an update that I ran my preset bank file through a JSON parser and found two settings had a value of "-nan", which isn't valid JSON. Those settings were:

"crybaby.wah" and "low_high_pass.lhc.low_freq".

Changing both of those values to 0 (zero) allowed me to load my preset bank. Not sure if that's any help to anyone else, but I'm pleased to have not lost my settings.

[Andreas Degert]

Hi,

I've also tested the behavior of MIDI controller updates. On my laptop (intel core i5 2.3GHz) the GUI thread has about 20% CPU load when the CPU frequency is fixed to 800MHz and a MIDI controller pedal is wiggled quickly. I'm using Ubuntu Unity which is based on the compositing window manager compiz. So it might be a different behavior than with a window manager which uses direct drawing to X11.

The realtime part and the GUI are totally decoupled for MIDI events. The events delivered by jackd modify the parameter values directly in RT context, and the GUI uses polling to check for changed parameter values. The polling timeout is 60ms (Glib::signal_timeout in gx_paramtable.cpp line 372, calling check_midi_values()). There is also the 60ms polling timeout for meter display (meter_display_timeout in gx_main_window.cpp line 2646), which is independent from MIDI update but also produces GUI load. You could change these timeouts to larger values (the locations are referencing the current git version).

If you use a USB sound device it might help to use a realtime Linux kernel and make sure that the threaded IRQ process priority for the USB IRQ handler is above the jackd priority. Changing to the other jackd implementation might also help (I had xruns without messages when the RT load was above 50% with one of them, don't remember if it was jackd1 or jackd2). xruns in the audio stream / USB system could also lead to missed MIDI events which could explain the erratic controller behavior.

greetings
Andreas

[Jesse Lang]

If you use a USB sound device it might help to use a realtime Linux kernel and make sure that the threaded IRQ process priority for the USB IRQ handler is above the jackd priority.

I see the realtime image available for Debian Wheezy. I'll install that. Can you offer some direction how to ensure the IRQ process priority is higher than jackd?

Changing to the other jackd implementation might also help (I had xruns without messages when the RT load was above 50% with one of them, don't remember if it was jackd1 or jackd2). xruns in the audio stream / USB system could also lead to missed MIDI events which could explain the erratic controller behavior.

I'll try the other implementation and see if that makes a difference. Perhaps my jackd settings are a little too aggressive at 3 periods of 128 samples. I'll try 256 and see if that makes a difference.

Thank you both for your continued support.

[brummer]

Here you will find some hints for IRQ prio setting:
http://subversion.ffado.org/wiki/IrqPriorities

greets
hermann

[Andreas Degert]

2013/10/3 Jesse Lang jesselang@users.sf.net

Just an update that I ran my preset bank file through a JSON parser and
found two settings had a value of "-nan", which isn't valid JSON. Those
settings were:

"crybaby.wah" and "low_high_pass.lhc.low_freq".

Changing both of those values to 0 (zero) allowed me to load my preset
bank. Not sure if that's any help to anyone else, but I'm pleased to have
not lost my settings.

I have seen that problem before, but I don't know the cause since I've
never been able to reproduce it. There is even code in Guitarix when it's
compiled in debug mode which should trigger an assert if nan's are created.
Sorry that it bit you.

---

• [bugs:#11] http://sourceforge.net/p/guitarix/bugs/11/ Audio crackles
  during gain parameter changes; GUI is suspect*

Status: open
Created: Tue Sep 10, 2013 06:16 AM UTC by Jesse Lang
Last Updated: Mon Sep 30, 2013 08:07 AM UTC
Owner: nobody

Hi.

First, please accept my gratitude for a very useful application. Thank you.

That said, I've got guitarix (latest git as of 9/9/13) running on an Intel
P4 Mobile 1.8Ghz notebook with 1G RAM. Not the fastest hardware, but in my
mind, certainly adequate for the application domain.

I'd be running on a Raspberry Pi, but I'm having problems with my chosen
USB audio interface on the Pi hardware. That is another story. :-)

This notebook is running Debian Wheezy. The issue I'm about to describe
exists in the Debian package of guitarix (0.22.4-1) as well, but it seems
more frequent with the latest git.

When using my MIDI foot controller's expression pedal to change the pre
and post gain settings, occasionally, the audio will break into static for
a split second. With the latest git, I noticed that the server and the GUI
client had been abstracted (hurray!), so I decided to see if that offered a
different result. The server (guitarix -N) did not exhibit the issue. So I
figured I would try the GUI client with the server, since I use Live Mode.
With the GUI client running, the issue presented.

Using top to monitor the processes, I could clearly see it was the GUI
client process that increased substantially in CPU usage when the
expression pedal was in consistent use. The server process stayed around
25%-30%, and the GUI process went from 20% to the 50%-60% range.

Also, I will mention that in Live Mode on latest git, the control
parameter meters don't respond as smoothly to value changes as they do in
the Debian package.

I would appreciate any help you could offer in troubleshooting and
resolving these items.

Thank you!

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/guitarix/bugs/11/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Jesse Lang]

This was resolved by increasing the buffer size in JACK. I was unable to get the realtime kernel running on my hardware. Thanks.