Welcome, Guest. Please login or register.

Author Topic: jump tables (-Edit- Eliminating conditional statements :-))  (Read 13747 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Kronos

  • Resident blue troll
  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 4017
    • Show all replies
    • http://www.SteamDraw.de
Re: jump tables
« on: February 22, 2005, 12:59:11 PM »
Now let's muddle the topic even more.....

@Bloodline
Is this virtual DSP supposed to work on the audio-stream in real-time (while it is being played), or will it modify audio-files ?

In the 1st case you would need some sort of external/reliable clock as you never know at what clock the CPU is running, and what other SW sucks at it.

In the 2nd case timing would be pretty much irrelvant (your not planning any parallel-computing I assume).

If timing is important, you can just forget about JIT (since translation takes time and it takes it while the DSP-program is running). You might use some sort of pre-compiling, but I how doubt that you will get much speed-benefit over the func-table.
1. Make an announcment.
2. Wait a while.
3. Check if it can actually be done.
4. Wait for someone else to do it.
5. Start working on it while giving out hillarious progress-reports.
6. Deny that you have ever announced it
7. Blame someone else
 

Offline Kronos

  • Resident blue troll
  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 4017
    • Show all replies
    • http://www.SteamDraw.de
Re: jump tables
« Reply #1 on: February 22, 2005, 02:12:00 PM »
Since you alllrady cuted the stream into pieces, with "best used by" date, you shouldn't even have to worry about timing at all.

The question is just if the maximum time a filter needs is still in time on the specific computer in the a specific load-situation is still within limits. Thats something decided by the user and the coder of the filter. If a package is done faster, no prob....

So the question is, how many free cycles you still have after applying the effect to every sound-bit of the stream, and wether that is enough for decoding.
 
If not, you'll need pre-compiling (no decoding during run-time).

Hah, now I'm quite happy again doing the completly timing-issue free stuff I'm doing  :-D
1. Make an announcment.
2. Wait a while.
3. Check if it can actually be done.
4. Wait for someone else to do it.
5. Start working on it while giving out hillarious progress-reports.
6. Deny that you have ever announced it
7. Blame someone else
 

Offline Kronos

  • Resident blue troll
  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 4017
    • Show all replies
    • http://www.SteamDraw.de
Re: jump tables
« Reply #2 on: February 22, 2005, 06:03:00 PM »
More food for thought:

I don't know much about DSPs, but....

One filter-function could easily consist out of hundred commands.
The sequence would need to be called for every word of the stream (at
the same fequence as the sampling-frequency).

Could result into 10000 and more commands to be decoded for each 10ms
part.

But since you don't plan to simulate a real DSP, you could create one
that applies commands to every sample in the 10ms-part.

Commands that has commands more sophistacted that the typical
RISC-like DSP-opcodes.

And/or make sure that the interaction between 2 opcodes is clearly
defined, allowing the translation-blocks to be just cued together,
with the right add filled in for any conditional possible (that would
pretty much be the pre-complile case).
1. Make an announcment.
2. Wait a while.
3. Check if it can actually be done.
4. Wait for someone else to do it.
5. Start working on it while giving out hillarious progress-reports.
6. Deny that you have ever announced it
7. Blame someone else