[linux-audio-dev] XAP: a polemic

Frank van de Pol fvdpol at home.nl
Mon Dec 16 08:27:01 UTC 2002


On Mon, Dec 16, 2002 at 01:43:03AM +0100, Tim Goetze wrote:
> 
> >Standing proposal:
> > Host processes blocks of 'n' samples.  Events are delivered with a
> > timestamp that says 'actuate this event at this time within this buffer'.
> > This is exactly what user-supplied automation is, totally randomly timed
> > events.  Some plugins need to sync to tempo or music-milestones.  They
> > indicate this need and receive tempo, meter, ticks events. It is
> > responsible for tracking changes.
> 
> drop the tick events and it starts to sound reasonable. 
> 
> buffer-relative timestamps are a definite no. 
> 
> reason: you need to be able to schedule events far 
> ahead (streaming, prequeueing). calculating a buffer-
> relative time in this case requires either knowing 
> all future buffer sizes or updating these events at 
> every cycle. the latter is too awkward, and the former
> enforces a guarantee that severely limits the system's
> synchronization capabilities.
> 

I thought the assumption was to send only events scheduled for the block te
be processed. If that is the case all tempo based, musical time references
can be converted into sample relative time (eg. sample number within the
block). If the block is to be rendered; it's too late make changes. Block
sizes[1] determine your latency.

If you are scheduling events ahead of the buffer, a few interesting things
happen:

- the plugin needs to have some events queued in musical time reference
  (tick) to be able to anticipate tempo changes no known at the time the event
  was scheduled (eg. for synching he position)

- In case of real-time changes to the song, events would need to be
  adjusted/deleted/inserted. This is something better handled at the
  sequencer host 

- In case of repositioning, skipping, reversing and other things a user can
  do with her jog dial, the queue needs to be adjusted appopriate. Same as
  #2


My votes for normalising event timestamps to buffer relative sample
position.

Perhaps a callback to get the actual tempo etc info from the host for those
plugins that require it (say: tempo delay) would be the best solution. 

Frank.


[1] - in case of lots of blocks in series; the latency might end up being
quite substantial, or am I overlooking something? If this is true, a setup
(I compare it to my mixing desk with some outboard processors) with varying
number of plugings for every channel would have different latency for
differenct channels. 


-- 
+---- --- -- -  -   -    - 
| Frank van de Pol                  -o)    A-L-S-A
| FvdPol at home.nl                    /\\  Sounds good!
| http://www.alsa-project.org      _\_v
| Linux - Why use Windows if we have doors available?



More information about the Linux-audio-dev mailing list