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

Winfried Ritsch ritsch at iem.at
Fri Nov 6 09:56:14 CET 2009


On Thursday, 5. November 2009 20:59:32 you wrote:
> Hi all,
> 
> There's no way from within Pd -- that would necessitate adding something
> to the API between Pd and the audio subsystem to make a direct call to
> alsa (or whatever).  Since you wrote most of the alsa code, I bet
> it would be easy for you to hack it in :)
> 
Thanx, I suspected this, but wanted to get sure about this. 

Ok I will see for a more general solution which can be adapted to other 
drivers like jack or on other OSes (in a month or so).

mfG 
 winfried 




> Miller
> 
> On Thu, Oct 29, 2009 at 01:58:37PM +0100, Winfried Ritsch wrote:
> > 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/)
--




More information about the Pd-dev mailing list