Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

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

open
nobody
None
v1.0_(example)
1
2013-09-30
2013-09-10
Jesse Lang
No

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!

Related

Bugs: #11

Discussion

  • Andreas Degert
    Andreas Degert
    2013-09-10

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


    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/

     

    Related

    Bugs: #11

    • Jesse Lang
      Jesse Lang
      2013-09-10

      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
    Andreas Degert
    2013-09-11

    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
    brummer
    2013-09-14

    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
      Jesse Lang
      2013-09-14

      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
    brummer
    2013-09-14

    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.

     
    Last edit: brummer 2013-09-25
    • Jesse Lang
      Jesse Lang
      2013-09-26

      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
    brummer
    2013-09-26

    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
      Jesse Lang
      2013-10-01

      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
        Jesse Lang
        2013-10-02

        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
    Andreas Degert
    2013-09-30

    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
      Jesse Lang
      2013-10-01

      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.

       
  • Andreas Degert
    Andreas Degert
    2013-10-04

    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.


    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/

     

    Related

    Bugs: #11


Anonymous


Cancel   Add attachments