If your clock error is x% then you can only sleep
>(100-x)%. I picked the half-way point because it's easy to visualize the
>methodology, but 90% or even 99% is sure to work (just don't try
>99.999%).
:-)
>different from the receiving clock you'll get a buffer underrun or
>overrun causing a major whammy in your received data stream. Suppose you
>have 100 radio listeners; the ones whose audio card clocks are closest to
>the server's audio clock frequency will "stay on the broadcast" the
>longest, while those with larger errors will suffer the buffer
>under/over-run condition sooner.
This is mostly poor driver design. There's insufficient fifo buffering to
handle the jitter.
>Hmm. Your code snippet shows that SysSleep() doesn't support partial
>seconds but I just retested my software and SysSleep() will accept a
>fractional portion of a second (i.e. SysSleep(1.5)) _and_ will sleep for
>partial seconds.
The code I posted is from toolkit samples. Looking at the string2long()
in the samples, 1.5 will be accepted and will be silently truncated to 1.
It was never advertised as the current implementation shipped in RexxUtil.
It does appear that the shipping RexxUtil code was changed and the docs
were not, which is good for you. Here's a quick test that seems to
confirm your findings.
[j:\tmp]rexxtry say time('E');call syssleep(2.4);say time('E') 0
2.420000
This is with the OREXX RexxUtil of circa 2000 which advertises itself as
[j:\tmp]rexxtry say sysutilversion()
2.00
>Hmm. Your toolkit and my SysSleep() don't seem to match.
Not terribly unexpected. It is sample code, not the shipping sources of
the current RexxUtil.
Steven
--
----------------------------------------------------------------------
"Steven Levine" MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4
www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
----------------------------------------------------------------------
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"postmaster@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 12 |
September |
2006 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
