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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list