H9000 Control timing

[nickrose]

There is always a risk of "rubberiness" on a multiprocessor system, due to communication issues.

But, I can tell you that the Orville UI processor ran at 25MHZ, whereas the one in the H9000 runs at 400MHZ. You can imagine that there is quite a difference in responsiveness.

Why do we not run a 3GHz Intel ? Because the unit is expensive enough and big enough already. You would not want it to have the noisy fan from a PC.

 

[cbm]

nickrose wrote:

But, I can tell you that the Orville UI processor ran at 25MHZ, whereas the one in the H9000 runs at 400MHZ. You can imagine that there is quite a difference in responsiveness.

Ignoring the front panel UI, a (very) crude way of analyzing this is that each Orville DSP engine got 12.5 MHz of clock cycles, and each H9000 will get double that. Better, but still not that great.

At some point in the future, it would be great to be able to throw a DSP engine core at the control stuff in an effects chain. For much of the stuff I do, three DSP engines per chain would be plenty, and having more rhythimic stability is more important. I know that this presents some archetectual challenges, but it’s probably easier than communicating across chips.

 

[ThreeFingersOfLove]

cbm wrote:

nickrose wrote:

But, I can tell you that the Orville UI processor ran at 25MHZ, whereas the one in the H9000 runs at 400MHZ. You can imagine that there is quite a difference in responsiveness.

Ignoring the front panel UI, a (very) crude way of analyzing this is that each Orville DSP engine got 12.5 MHz of clock cycles, and each H9000 will get double that. Better, but still not that great.

At some point in the future, it would be great to be able to throw a DSP engine core at the control stuff in an effects chain. For much of the stuff I do, three DSP engines per chain would be plenty, and having more rhythimic stability is more important. I know that this presents some archetectual challenges, but it’s probably easier than communicating across chips.

If we take into account that it has 16 DSP, and the available UI computational resources are divided equally among those DSP, then indeed 25 MHz is not enough

[cbm]

 

I’m wondering if there’s any improvement on the timing accuracy of things calculated at control rate. On my Orville, things calculated at control rate can get a little “lumpy”. I have patches that should be rhythmic, but only sort of are. I’ve always chalked this up to a week scheduler running on the CPU, which I’m sure can get busy. As I understand it, the H9000 has a fifth CPU that handles the UI and other system stuff. Is it enough faster to get the job done better than on the Orville? Given that there are many more DSP engines to service I worry that timing will stay a little erratic. 

 

UI response can also be quite sluggish on the Orville. Any improvements on this for the H9000?

 

[nickrose]

I would argue that however much bandwith you have, you can use it all up.

I would also say that while you might have x amount of remote modulation for one dsp, you are unlikely to have 16x for 16 dsps.

You would probably saturate the MIDI, if nothing else.

 

[cbm]

This track tries to illustrate some of the timing problems when passing signals betweeen the audio and control sides of an Orville.

In this algorithm, there are a series of 12 delays, in series. Each delay gets “blipped” to the output. The blip envelopes are generated from an LFO which gets passed to the control side to drive a counter and a bunch of comparators to decode the counter. The decoded triggers are passed back to the audio side to drive the envelopes.

As you can hear, the rhythm is not so steady. If I had to guess, it sounds like a simple main loop scheduler on the control side. Hopefully this sort of thing will be much better in the H9000.

.sig file upon request.

https://soundcloud.com/cbm/bubble-timing-ex01/s-7L9P5

[ThreeFingersOfLove]

cbm wrote:

This track tries to illustrate some of the timing problems when passing signals betweeen the audio and control sides of an Orville.

In this algorithm, there are a series of 12 delays, in series. Each delay gets “blipped” to the output. The blip envelopes are generated from an LFO which gets passed to the control side to drive a counter and a bunch of comparators to decode the counter. The decoded triggers are passed back to the audio side to drive the envelopes.

As you can hear, the rhythm is not so steady. If I had to guess, it sounds like a simple main loop scheduler on the control side. Hopefully this sort of thing will be much better in the H9000.

.sig file upon request.

https://soundcloud.com/cbm/bubble-timing-ex01/s-7L9P5

This is all over the place… Do the Orville and the H8000FW have the same UI refresh frequency?

[cbm]

After a few days more work on this algorithm, I have managed to migrate most of the timing and cell selection logic stuff to the DSP side, and the timing is solid there. The trouble is, the likely objects that I wanted to use to express the logic of this algorithm are on the control side, and may only have murky counterparts on the DSP side.

For example, using an LFO to scan through a a bunch of sequencers seemed like a reasonable approach to generate triggers for the envelopes, but the LFO doesn’t have a true sawtooth, so all the sequencer stages fire during the LFO “flyback.” I worked around this by gating the output of the LFO when it was falling, which is a sort of ugly bandaid, involving a PICODELAY, COMPARATOR, BOUND, and CROSSIN.

This sort of issue popped up a few times when trying to do moderately complex logic things on the DSP side. There are still a couple things I’m trying to improve in this patch, but it’s right on the edge of what the Orville will load. Here are a couple longish examples of the now usable patch in action:

https://soundcloud.com/cbm/bubble-timing-ex02

https://soundcloud.com/cbm/bubble-mod

These are both real-time improvs

[jbamberg]

On the Orville, and H8000FW, the central control processor runs the UI and also the control code of the algorithms.  So, UI responsiveness and control rate are intimately tied together.  The H9000 is different, in that the control code runs on the DSPs, but the UI still runs on the main control processor.  Effectively, what this means is that the control rate of the H9000 should be faster than on the Orville/H8000FW – not only is it not waiting for the UI, but it runs on a much faster processor (1GHz).  I don't have any actual measurements to back this up, but when I have some time to gather some, I will.

Regarding the occasional slowness of the UI on the Orville/H8000FW, this should also be improved on the H9000 for the same reasons.   The central processor does a lot of tasks, including networking and MIDI, and the UI is also quite a lot more graphically complex, but we've done our best to keep it snappy and responsive.

 

[cbm]

jbamberg wrote:

On the Orville, and H8000FW, the central control processor runs the UI and also the control code of the algorithms.  So, UI responsiveness and control rate are intimately tied together.  The H9000 is different, in that the control code runs on the DSPs, but the UI still runs on the main control processor.  Effectively, what this means is that the control rate of the H9000 should be faster than on the Orville/H8000FW – not only is it not waiting for the UI, but it runs on a much faster processor (1GHz).  I don’t have any actual measurements to back this up, but when I have some time to gather some, I will.

Regarding the occasional slowness of the UI on the Orville/H8000FW, this should also be improved on the H9000 for the same reasons.   The central processor does a lot of tasks, including networking and MIDI, and the UI is also quite a lot more graphically complex, but we’ve done our best to keep it snappy and responsive.

It sound like control rate things might be in better shape on the H9000. Can you comment on what sort of scheduler is running the control stuff?

[jbamberg]

cbm wrote:

It sound like control rate things might be in better shape on the H9000. Can you comment on what sort of scheduler is running the control stuff?

Well, the control code is run at a lower priority than the audio processing.  So, you can't rely on the control loop to execute with any particular frequency as it depends on how busy the DSP is doing real-time audio processing.  As the DSPs have four cores, the OS can spread the control processing across all of them, so if you have one or two algorithms that are very DSP intensive, they probably won't affect the control code too much, since it will just be scheduled on the cores that are less busy.

 

[Author]

Posts