Subject: Re: [linux-audio-dev] P&S: buffer pointer update events and time
From: David Olofson (audiality_AT_swipnet.se)
Date: ti tammi 11 2000 - 20:02:54 EST
On Sun, 09 Jan 2000, Roger Larsson wrote:
> Problem:
> Normally an event has a time when it is to be executed.
>
> This gives a problem with the suggested (as I understand it)
> "new buffer pointer event" and transferring data over any form of
> IPC (inter process communication). Since IPC can be faster then the
> current data rate you should be able to write it all out and return.
> But it is not possible since the size of the data is not known until
> next buffer update event arrives.
The simple rule is "Process data until you reach the time stamped on
the last event you have recieved so far." This is what the average
plugin would do inside it's event decoding loop, and the most obvious
differences between plugins and clients are:
1) Plugins return where clients sleep.
2) Plugins get time 0 on the first frame of each call, while
clients have a constantly running (and possibly wrapping) time.
> Observation:
> A event can only describe what has happened up to this time, it can
> not see into the future.
An event *can* say what it wants the recipient to do N frames into
the future (return/sleep for example), but that would a) break the
logic of the event concept, and b) be rather useless, as an efficient
event decoding loop will still parse all events, checking the time
stamp of the next event to know how many frames to process before
decoding it.
> Solution:
> Time (see "T&S: time") duration of valid buffer.
> When the duration has expired the plugin expect/requests a new.
No, that requires an extra test that the plugin or client has to
perform all the time. I'd use a terminator event, as that means
overhead only when that event is received. For clients, that event
also solves the problem of not knowing how much data there is
following the last normal event received.
> Note:
> time format contains both number of samples and sample frequency
> in this case.
(I think the sample rate should go in the format description of the
buffer, along with sample byte size (for audio data) and so on.)
//David
.- M u C o S -------------------. .- A u d i a l i t y ----------------.
| A Free/Open Multimedia | | Rock Solid, Hard Real Time, |
| Plugin & Integration Standard | | Low Latency Signal Processing |
`------> www.linuxdj.com/mucos -' `--> www.angelfire.com/or/audiality -'
.- D a v i d O l o f s o n ------------------------------------------.
| Audio Hacker, Linux Advocate, Open Source Advocate, Singer/Composer |
`----------------------------------------------> audiality_AT_swipnet.se -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST