alsamodular-user

[Bill Y. <yer...@ya...>]

I went into hacker mode last night and came up with the following patch that
seems to fix the problem (at least I can loop VCOs and get reasonable 
sounding FM modulation).  

NOTE TO MAINTAINERS: Please consider this patch for inclusion in the mainline
of AMS.    - Bill Yerazunis.

The high level problem seems to be that getData is called by PCMout modules, 
and the request for data propagates back through all of the modules attached to
the PCMout (note that just looping a pair of VCOs in FM mode does NOT cause the
recursive call segfault.  This request-for-data propagates backward as a depth-first
span of the AMS patch.  The segfault only occurs when you attempt to take the
_output_ of such a loop and send it to the outside world- that was a critical clue)

The (hack) fix is to detect that we;re in such a infinite loop within the same 
getData cycle, and break the infinite loop by using the _previous_ cycle's data
as a stand-in for the fresh data, just so the module earlier in the cycle can finish 
computation and return a value to the current module.  

Anyway, it does mean that there's a tiny delay inserted (1/44,100th of a second) in
such loops, which isn't mathematically _exact_ but it seems to work just fine.

Here's the actual patch (sorry it's not in a pretty format):

In file "module.h" at line 95, add the line to add "bool alreadyAsked":
    ....
    bool cycleReady;
    bool alreadyAsked;   // WSY:20110208: fix for on-demand eval loop bug       
    M_typeEnum M_type;
    ....


Then, in file "module.cpp", at line 359, you will find the function Module::getData(index).
Here is the fixed getData (note: I commented out the original code so you can see 
what changed easily).

* * * * * * * * * * CUT HERE CUT HERE CUT HERE CUT HERE * * * * * * * 

float **Module::getData(int index)
{
  //  WSY: 20110208: Fix for on-demand eval loop bug                             
  //  if (!cycleReady) {                                                         
  //      generateCycle();                                                       
  //      cycleReady = true;                                                     
  //  }                                                                          
  //  return data[index];                                                        
  //                                                                             
  if (alreadyAsked)
    {   // If we've already requested this port's data, break the                
      //   infinite loop by returning slightly stale data.                       
      return data[index];
    };
  if (!cycleReady)
    {
      alreadyAsked = true;
      generateCycle();
      cycleReady = true;
      alreadyAsked = false;
    };
  //    WSY:  End of fix for on-demand eval loop bug.                            
  return data[index];
}

* * * * * * * * * * CUT HERE CUT HERE CUT HERE CUT HERE * * * * * * * 


Anyway, give that a try.  
 
     - Bill Yerazunis


--- On Tue, 2/8/11, Julian <nab...@gm...> wrote:

From: Julian <nab...@gm...>
Subject: Re: [Alsamodular-user] looped patch -- > instant segfault
To: "Bill Yerazunis" <yer...@ya...>
Date: Tuesday, February 8, 2011, 5:37 PM

This list can probably get me back in time: http://sourceforge.net/projects/alsamodular/files/alsamodular/ , I will try to build the previous one soon. As for the system I got 2 gig of memory and dual core 1.73GHz. I don't know if it really was that long but it didn't go as fast as I had hoped.


Btw if you look at the list archive you see I made a new post instead of a reply, I just can't find out how to reply in mail lists ;D
(too used to forums obviously)

Julian


On Tue, Feb 8, 2011 at 11:13 PM, Bill Yerazunis <yer...@ya...> wrote:

Julian:

Interestiing that it used to work!   

Is there any way you can recover the version number of AMS that it worked 

correctly on?  If so, we can do a diff and see what changed; maybe it's something
simple. 

Or then again, maybe it won't be something simple....  can any of the developers shed any light on this?   Changing the architecture from an "evaluate on every cycle" to "evaluate only on demand" would cause this bug.  


(nb: I'm building it from source on a Core 2 Duo 2.4Ghz (4775 BogoMips) and it builds in a minute or two from "clean".   What are you building on that makes it so slow?)

    - Bill Yerazunis


--- On Tue, 2/8/11, Julian <nab...@gm...> wrote:


From: Julian <nab...@gm...>
Subject: Re: [Alsamodular-user] looped patch -- > instant segfault
To: als...@li...

Date: Tuesday, February 8, 2011, 3:52 PM

Hey Bill, I have the exact same problem, and I did too post here about it.
I also just tested your observation about when it occur, and yes, it wont happen if they aren't connected to an output, but I tried it even with the scope (oscilloscope module) and the whole program disappeared instantly. 



This didn't use to be a problem for me, in a previous version of Ubuntu I could easily send signals back in a loop, but now I can't.
I do not know if the AMS version has changed since then, but I believe it has, and might be the cause of the problem.


Could somebody confirm that they 'do not' have this problem, in the newest version (2.0.1)?


Btw, I have managed to compile this program (though it takes forever(like all programs)). Is there any simple change in the code you could think of that would help?



Thanks
Julian



-----Inline Attachment Follows-----

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:

Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

-----Inline Attachment Follows-----

_______________________________________________
Alsamodular-user mailing list
Als...@li...

https://lists.sourceforge.net/lists/listinfo/alsamodular-user