Loading ...
Sorry, an error occurred while loading the content.

cpu usage question

Expand Messages
  • James Forrest
    Hi Phil or whoever else might know, I very often reach CPU usage limits even though my patches aren t particularly complex. So I tried an experiment. I set
    Message 1 of 5 , Sep 1, 2001
    • 0 Attachment
      Hi Phil or whoever else might know,

      I very often reach CPU usage limits even though my
      patches aren't particularly complex. So I tried an
      experiment. I set up a patch in SuperCollider and one
      in JSyn to see how many sine oscillators I could have
      in each to produce a CPU usage of 50%. In JSyn 47
      oscillators gave a usage of 50%. In SuperCollider 120
      oscillators gave a usage of 50%. What could account
      for this large discrepancy? In the JSyn circuit I was
      using 47 SineOscillator's, 47 BusWriters and one
      BusReader to add them together, and one LineOut. In
      SuperCollider, I was using 120 SineOsc uGens, and one
      Spawn.

      -Could it be the overhead of the JVM?
      -Could it be the fact that I needed to use 47
      BusWriters?
      -Could it just be that the implementation in
      SuperCollider is faster than the one in CSyn?

      I want to address this issue in a paper I'm working
      on, but I want to be well informed of the causes.

      Thanks,
      -Jamie Forrest

      __________________________________________________
      Do You Yahoo!?
      Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
      http://im.yahoo.com
    • Phil Burk
      From: James Forrest ... There could be a lot of reasons for this. James McCartney, who wrote SuperCollider, may have used a
      Message 2 of 5 , Sep 1, 2001
      • 0 Attachment
        From: "James Forrest" <honksandsirens@...>
        > In JSyn 47
        > oscillators gave a usage of 50%. In SuperCollider 120
        > oscillators gave a usage of 50%. What could account
        > for this large discrepancy?

        There could be a lot of reasons for this. James McCartney, who wrote
        SuperCollider, may have used a different algorithm for his sine wave
        generators. Were the frequencies of the sine waves varying? If not then
        James might have selected a CORDIC implementation that requires very few
        multiplies. The CORDIC algorithm is basically a ringing filter. But the
        CORDIC implementation is not efficient if you modulate frequency because
        then you have to do a SIN calculation to convert frequency to the filter
        coefficient.

        I use a Taylor expansion out to the X^11 stage to generate sine waves. This
        gives better than 16 bit resolution, and also has linear frequency control
        so it is better at doing FM than the CORDIC.

        Try hooking up the sine oscillators so that they modulate each others
        frequency and amplitude in a chain. The performance in JSyn should not
        change but the numbers in SuperCollider may go down.

        Another possible implementation would be to use a sinewave table lookup. On
        the PC, I prefer the Taylor expansion because it does not trash the data
        cache as much as a table lookup. But maybe table lookup is faster than
        Taylor expansion on a Macintosh.

        Also James might have used assembly language or SIMD optimization but I
        don't think so. He told me that he likes to write pure 'C' that he optimizes
        based on the assembly code it produces.

        > -Could it be the overhead of the JVM?

        No. The JVM is not involved in synthesis.

        > -Could it be the fact that I needed to use 47 BusWriters?

        Possibly. Try using AddUnits instead.

        Phil Burk
      • James Forrest
        From: Phil Burk ... not then ... that requires very few ... ringing filter. But the ... modulate frequency because ... frequency to
        Message 3 of 5 , Sep 1, 2001
        • 0 Attachment
          From: "Phil Burk" <philburk@...>
          > Were the frequencies of the sine waves varying? If
          not then
          > James might have selected a CORDIC implementation
          that requires very few
          > multiplies. The CORDIC algorithm is basically a
          ringing filter. But the
          > CORDIC implementation is not efficient if you
          modulate frequency because
          > then you have to do a SIN calculation to convert
          frequency to the filter
          > coefficient.

          The frequencies weren't varying in my first test,
          although the SinOsc uGen
          that I used in SuperCollider does support frequency
          and amplitude
          modulation. There is an FSinOsc that is a faster uGen
          that does not support
          modulation, but I was using SinOsc in my test.

          > Try hooking up the sine oscillators so that they
          modulate each others
          > frequency and amplitude in a chain. The performance
          in JSyn should not
          > change but the numbers in SuperCollider may go down.

          I tried this, and there wasn't any difference in
          either JSyn or
          SuperCollider. They both had the roughly same usage
          stats as they did in
          the "unmodulated" versions.

          > > -Could it be the overhead of the JVM?
          >
          > No. The JVM is not involved in synthesis.

          Even if it's not involved in synthesis, doesn't any
          JVM activity that's
          currently taxing the processor at least get in the way
          of the synthesis? Or
          is the CPU load of the JVM so slight compared to that
          of the synthesis that
          it's insignificant?

          >
          > > -Could it be the fact that I needed to use 47
          BusWriters?
          >
          > Possibly. Try using AddUnits instead.

          I tried it again using AddUnits, and although the
          usage was a little better,
          it still did not compare to the usage in
          SuperCollider.

          By the way, these tests were performed on a Macintosh
          Powerbook G3 400 MHz.
          I also tried the JSyn test on my (slower) PC (for
          obvious reasons, I
          couldn't test SuperCollider on my PC!). My PC is a
          300 MHz PII (hey, it was
          fast in '97) and I was only able to get 29 oscillators
          with 50% usage.

          -Jamie


          __________________________________________________
          Do You Yahoo!?
          Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
          http://im.yahoo.com
        • Sandra Wilson
          I need to play a sample, varying the pitch and dynamics over time. Currently I have the sample going into the sample port of the SampleReader_16V1, the output
          Message 4 of 5 , Sep 3, 2001
          • 0 Attachment
            I need to play a sample, varying the pitch and dynamics
            over time.

            Currently I have the sample going into the sample port of
            the SampleReader_16V1, the output from an EnvelopePlayer
            (which provides the dynamic envelope) going into the
            amplitude port of the SampleReader_16V1 and a set figure
            for the frequency going into the rate port of the
            SampleReader_16V1.

            Is it possible to replace the set frequency going into the
            rate port with another EnvelopePlayer which would provide
            an envelope to control the changing frequency over the
            duration of the sample?

            If not, do you have any suggestions on how I could achieve
            my aim?

            Thanks in advance (and also for previous help).

            Sandra.

            ----------------------
            Sandra Wilson
            mamscw@...
          • Joachim Gossmann
            Hi Sandra, ha... that s something I think I know how to do! :) It s actually not too complex: All you have to do is create an EnvelopePlayer for your pitch
            Message 5 of 5 , Sep 3, 2001
            • 0 Attachment
              Hi Sandra,

              ha... that's something I think I know how to do! :)

              It's actually not too complex:
              All you have to do is create an EnvelopePlayer for your pitch envelope and
              "connect" it's output to the rate-field of the SamplePlayer, instead of
              "set", just like you probably did for the amplitude.
              ... somewhat like this:


              PitchEnv = new EnvelopePlayer();
              SamplePlay = new SamplePlayer_16V1()

              PitchEnv.output.connect(SamplePlay.rate);


              There might be more useful info for you at:

              http://www.softsynth.com/jsyn/tutorial/

              Greetings,

              jo
            Your message has been successfully submitted and would be delivered to recipients shortly.