[PD-dev] LogicalRealtime needed (was Re: [PD] packOSC TimeTag realtime vs. logicaltime)

[Winfried Ritsch]

Hello,

Sending audio over OSC needs a accurate time-tag in sync with Audio on the 
sender so packages can be ordered, and re-sampling with the audio-sync on the 
receiver, but OSC is defined to use the universal sync the Internet time 
(realtime).

Syncing computers over Internet time is already a solved problem;using adequat 
audio buffer there should be a stable solution. Since Audiotime is not in sync 
with real-time.

So we need a Locgical-Realtime on the sender, that means realtime corrected 
with the offset in the audio buffer processing, which should be fairly excat 
enough.

The question is now:

a) How can I get the offset of the actual audio-buffer processing to either 
the ADC-time oder DAC time, the the time at the beginning or end of the audio-
buffer in PD ?

a)if not possible Should we invent for this purposes a LocalRealtime for each 
audio-buffer and how ?


mfG 
 Winfried Ritsch

On Friday, 9. October 2009 05:54:25 Martin Peach wrote:
> Wolfgang Jäger wrote:
> > Hello,
> >
> > I'm using a combination of [pack~] [packOSC] -> transmission(UDP) ->
> > [unpackOSC] and a modified version of [unpack~] to send Audio over OSC.
> > The OSC packages are sent as Bundles so a TimeTag is generated at the
> > sender's side. I extended the [unpackOSC] object with another outlet
> > where I'm getting the particular TimeTag of each Bundle.
> > In the modified version of [unpack~] I evaluate these TimeTags with
> > regards to dropouts in the transmission.
> > My problem is that the TimeTags are not accurate, what I ascribe to the
> > fact, that the TimeTag in [packOSC] is generated as "real time" instead
> > of "logical time". Using "real time" the TimeTag-"Output" is a function
> > of the audiobuffersize (depending on the cpu load), so in my case, as
> > the CPU-load is quite big, the values of the TimeTags are not useable
> > for sequencing the datastream (as there are jumps in the TimeTag I
> > always assume some packages got lost).
> > As a workaround I established a sequence number, which is additionally
> > transmitted in each Bundle. This is an appropiate solution, but it
> > wouldn't be necessary if the TimeTag would be generated properly.
> > Are my considerations conclusive?
> 
> At the moment the timetag is calculated when the bundle is opened with
> the [ message. If the ] message doesn't occur at the same time the
> timetag will be wrong as the message doesn't start to get sent until the
> bundle is closed. Then there is the delay in the OS as it schedules the
> packet for the network and the network card deals with possible
> collisions with other packets, etc...
> As well, anything [packOSC] does occurs between audio blocks (and may be
> postponed if there is too much going on), so the timing will be jittery
> unless your packets are being composed and sent in precise sync with the
> audio. And if they are being sent to another machine with another clock
> of course this is never going to happen unless you can sync their sound
> cards via SPDIF or word clock. But that's real time.
> Because there is no way to know what the 'logical time' is outside of
> your logical frame, just use the sequential block number as your logical
> time. Pack a sequence number followed by a blob, possibly resetting the
> sequence numbers when they get too big. No need for bundle or timetag.
> 
> Martin
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
>  http://lists.puredata.info/listinfo/pd-list
> 

-- 
--
- ao.Univ.Prof. DI Winfried Ritsch 
- ritsch at iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--