liblo-devel Mailing List for LibLO

Hi,

On Tue, Aug 19, 2008 at 4:25 PM, Dave Robillard <da...@dr...> wrote:
> Hi,
>
> Simple patch attached to hide the _internal methods from the
> documentation (they look pretty silly there...)

Thanks!
I think a slightly better way to do that (instead of putting a new
macro in the headers) is to use Doxygen's "\internal" command.
However this requires setting EXTRACT_ALL to "no", meaning that
undocumented functions don't get added to the documentation at all.
On the other hand, this just means they are lacking documentation, so
I think adding documentation for functions and structures that
disappear when EXTRACT_ALL is turned off is probably the way to go.
I'll try to work on this.

Steve

Hi,

Simple patch attached to hide the _internal methods from the
documentation (they look pretty silly there...)

Cheers,

-dr

Getting timestamps right is hard(tm), so I'll just add some  
observations here.

Jitter induced phase-modulation noise (which is frequency and  
distribution-dependent) is actually a significant problem even at  
gesture frequency rates.  Jitter on the order of a couple msec can  
easily degrade the channel to less than the equivalent of 8-bit depth  
quantization noise.  I wrote a paper about this, and the  
implementation of forward sync / backward re-sync in MaxMSP, available  
here:

http://cnmat.berkeley.edu/publication/implementation_and_applications_open_sound_control_timestamps

(its a preprint but if you make a user account the PDF can be  
downloaded, or email me off-list -- if you will be at ICMC 2008 you  
can talk to me about this in person at the poster session, Aug 28th,  
3:15 pm).

...

There are a few basic needs for a timestamp implementation:

1) ability to forward-queue, messages marked for the future to be  
"delivered" on-time

However this is only useful when the network delay is known by the  
remote client, which is actually more than often an unreasonable  
requirement.  For one, it is impossible unless the communication  
channel is bidirectional.  It also requires network clock sync.  In  
fact I only find this to be useful when the target is too dumb to  
compute the delay statistics itself (e.g. a microprocessor).


2) ability to backwards-queue, messages marked in the PAST to be  
delayed by an additional amount to a constant delay.

This is useful when the client has no idea what the network delay is-- 
it does not attempt to pre-delay messages by marking for the future,  
but just marks them for the PRESENT time...  then the host computes  
the delay statistics (assuming clocks are synchronized), formulates a  
target delay boundary, and reschedules delivery.  Also, if you are  
playing back data from the past (e.g. an OSC recording / playback  
system), the timestamps can be very far in the past.

Delay as a random process means that there also needs to be a way to  
dispatch messages that miss the resynchronization deadline.  Also  
messages marked "immediate" bypass the rescheduling entirely. Oddly  
enough I've found that in a system that actually uses timestamps for  
jitter compensation, the "immediate" tag is actually used for  
informational "out-of-band" type messages that are actually the lowest  
priority...  go figure.


3) ability to not apply any rescheduling at all, but to let the  
dispatch routine handle rescheduling...  every dispatch should have an  
associated timestamp.  With a typical soft-RT operating system the  
rescheduling accuracy is not better than about 1msec--which actually  
leaves a fairly large amount of phase-modulation noise in the signal.   
A system that interfaces to a synchronous domain (e.g. audio stream)  
can achieve accuracy down in the sub-microsecond range...  but that is  
obviously out of scope for liblo's purposes, so it needs to be able to  
let the user handle the scheduling, or at least not make the  
assumption that its attempted rescheduling is sufficient.


4) ability to queue a VERY LARGE number of messages into the  
schedule... like, thousands.  Use an O(1) priority queue, variable  
heap size, possibly adaptive...  this enables the use of high-latency  
block-based transports, e.g. file handles, databases.


Cheers--
Andy.


---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

Hi all,

I just tried out liblo's bundle timestamp handling and found it is still
too buggy to use.  This is a shame because otherwise it's a really great
library.  I had a look at trying to fix it myself before but didn't get
anywhere.

If a liblo server thread receives a bundle timestamped into the future
it queues up the messages within and tries to release them at the right
time.  However there is an error somewhere because there is heavy
periodic stuttering, I think every second.  Perhaps the fractional part
of the timestamp is not handled correctly.

In any case I think this queueing behaviour should be optional...  I see
that the motivation is to be able to send messages a bit ahead of time
so network latency/jitter gets ironed out.  But what about in the case
of a OSC proxy?  You'd want to forward the message with the same
timestamp, without delay.  Also, you might want your client and server
to operate on the same 'logical' time that appears in the bundle
timestamp so that their clocks are fully synchronised, at the moment
when you receive a delayed message that came from a bundle you have no
way of finding out what the timestamp on the bundle was (please correct
me if I'm wrong).

Anyone else have thoughts/experience with this?

Best wishes,

alex

On Tue, Aug 5, 2008 at 1:36 PM, Tristan Matthews <tr...@sa...> wrote:
> Hey,
>
> If you try to do autoreconf on the liblo directory with the latest
> autotools, it fails with the following error:
>
> src/Makefile.am:24: compiling `subtest.c' with per-target flags requires
> `AM_PROG_CC_C_O' in `configure.ac'
>
> I'm not sure but I think this issue has something to do with using an
> older version of autotools.

Yeah you're right, I see the error too.  Didn't notice it before.
(I think it usually scrolled right off the screen.)

Looks like adding AM_PROG_CC_C_O to configure.ac does indeed fix it
though, so I'll do it in SVN soon.

thanks,
Steve

Hey,

If you try to do autoreconf on the liblo directory with the latest 
autotools, it fails with the following error:

src/Makefile.am:24: compiling `subtest.c' with per-target flags requires 
`AM_PROG_CC_C_O' in `configure.ac'

I'm not sure but I think this issue has something to do with using an 
older version of autotools.

-Tristan