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 > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- -- - ao.Univ.Prof. DI Winfried Ritsch - [email protected] - 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/) -- _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
