Re: [linux-audio-dev] Re: A Plugin API

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: A Plugin API
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: ti helmi  29 2000 - 08:03:49 EST


>From: "Richard W.E. Furse" <richard_AT_muse.demon.co.uk>
>
>agree there's an ordering problem. Both A and B write into buf1, so the
>audio from A is overwritten before it reaches C.

Perhaps you're doing something wrong. As I see it, the above scheme is
possible if only what we try to do makes sense.

>A only writes to one place and no buffer copying is used

This is also not a problem.

 -*-

Now to my suggestion.

One buffer could have multiple read and write pointers.
A writer has to check all read pointers and write only up to
last read pointer. Writing would be additive, i.e., not replacive.
A reader would read up to next write pointer. Last read pointer
would reset buffer entries to zero.

Diagram of delay (buffer) element would help:

            delay increases --->
         |-------------------------------
         W1
          R1

  W1 = first write pointer
  R1 = first read pointer

As seen in the diagram, R1 has no delay with respect to W1.
That is the case of simplest buffers used as arcs.

            delay increases --->
         |-------------------------------
         WA WB
          RB
          RD

  WA = write pointer of A
  RB = read pointer of B
  WB = write pointer of B
  RD = read pointer of D

That is the case where your diagram 1 (buf1 twice) was wrong because
D actually reads output of A.

            delay increases --->
         |-------------------------------
         WA WB RD
          RB

  WA = write pointer of A
  RB = read pointer of B
  WB = write pointer of B
  RD = read pointer of D

That is the case when D reads output of B (and your diagram is
correct).

Note that first write pointer always locates at the left if we draw
that kind of diagrams.

Note that rightmost pointer should be a read pointer which also resets
buffer elements to zero.

Note that RD can read only up to next write pointer which is WD.
(If we allow jitter in reading, i.e., multiple samples per one read.)

Note that the diagram tells nothing about the actual buffer length.

 -*-

The implications are that we don't need separate "add", "delay" and
"divide stream" opcodes. "Divide stream" is an opcode which splits
the audio stream from one buffer to multiple buffers.

Juhana


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST