electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » Instruments and Equipment » OSX as a music workstation
Help! My MacBook Pro is suffering from Arrested Development
Post new topic   Reply to topic Moderators: elektro80
Page 1 of 1 [23 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Fri Jul 18, 2008 8:19 am    Post subject: Help! My MacBook Pro is suffering from Arrested Development
Subject description: Incoming network is spastic and Chuck makes snap, crackle and pop
Reply with quote  Mark this post and the followings unread

So, as some people who helped me out almost a year ago when I bought this machine know, I bought a MacBook pro last year to have a second portable machine for some electro-music applications, as a backup and hopefully a replacement for my lead weight, so called "portable" Alienware XP machine. In fact I bought 3 Macs last year, but my daughter's iMac is with her in New Mexico, and my son's MacBook Pro is in Canada with him at audio school. I'd like to have his at hand to compare with my problems, because he runs ProTools and other audio processing stuff on it, but he's not here.

Anyway, problem number 1 is incoming network traffic often has a terrible case of the slows. I've eliminated the wireless LAN by using wired, and it's not just the web. The XP machines in the house do fine on the web, and moreover -- and this is the important part -- I have a distributed music program I am working on that sends OSC-on-UDP datagrams around, at pretty coarse time granularity. Packets going out of the Macbook to the XP machines arrive at good speed, but the packets coming back to the Mac seem to take forever to get into the Mac and get processed, regardless of whether it is using the wireless or wired LAN. A crappy old Dell laptop that I have performs much better than the MacBook on receiving and using this incoming UDP-LAN traffic. So the consistent symptom here is very slow incoming network traffic, both with LAN-only-musical traffic and web traffic, and it's not tied to either the wireless or wired Ethernet hardware.

I can't find any place in the mac on-line UIs that let me monitor or try to fix the problem. Any suggestions? I've used Ethereal and other traffic analysis tools for years, but I don't see where OSx even gives me a way to look at the problem.

The other problem is that I tested a ChucK application that works fine on the Alienware machine on the MacBook, and on the Mac I get a lot of crackly noise that I don't get on the Alienware. Same Edirol sound box, same sampling rate. I tried playing with the buffers sizes, and also tried the Mac's built-in sound card, on the chance that the Mac Edirol driver is goofy, but still have the crackles. The machines are on par CPU and memory wise, about 3.5 GHz and 2 MB ram, and run the ChucK app in the mix with about a 30% CPU load, which should be fine.

There is something goofy with this machine, so that it winds up almost exclusively being used by my wife and visitors for email and web browsing, which is a big disappointment to me. Any suggestions on how to attack the problem? Thanks.

EDIT: Should have said 2 GB RAM.

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.

Last edited by Acoustic Interloper on Fri Jul 18, 2008 11:19 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 3868
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri Jul 18, 2008 10:02 am    Post subject: Reply with quote  Mark this post and the followings unread

Hi,

My MacBook Pro uses large amounts of cpu when it has a high network load, up to 80% cpu can be used copying a file to the MacBook over gigabit. I have never worked out why. Apparently they are not meant to.

You can get ethereal using macport http://www.macports.org/ first of all though I would do a simple test of copying a file to the macbook and having a look see if you suffer from the same cpu issue that I do although your issue sounds like it may be a bit different.

I don't know about the edirol device (is it usb?) but the core drivers for the onboard audio are bloody awful, they are real cpu hogs, my RME drivers use 50% of the cpu than the onboard drivers!

Definitely some developers code runs very badly on intel based macs, NI stuff tends to use twice the amount of cpu running on OS X as when running XP on my MacBook pro. I Don' know why, code I have written and benchmarked runs slightly slower under OS X, but not much.

Cheers

Andy
Back to top
View user's profile Send private message
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Fri Jul 18, 2008 11:33 am    Post subject: Reply with quote  Mark this post and the followings unread

BobTheDog wrote:
You can get ethereal using macport http://www.macports.org/ first of all though I would do a simple test of copying a file to the macbook and having a look see if you suffer from the same cpu issue that I do although your issue sounds like it may be a bit different.

I'll give it a try, thanks.

Quote:
I don't know about the edirol device (is it usb?) but the core drivers for the onboard audio are bloody awful, they are real cpu hogs, my RME drivers use 50% of the cpu than the onboard drivers!

The Edirol is USB, no hub, and the CPU load looks no worse than the Alienware XP machine. The OSC/UDP datagrams are quite small, 1000 bytes or so, and only 3 of them arrive after a player has made a move at distributed musical chess on a Python/Tkinter GUI running on the Mac, but it takes forever for them to come back. It's very strange -- a player moves a piece on the Mac, a small-data XML/RPC call gets made to the Alienware machine serving the game and normally running ChucK, you hear the sound change immediately, but it takes forever for the Mac display to update as the result of the 3 return UDP datagrams that describe the new board state. I would have thought the outgoing XML/RPC woul have been the bottleneck if anything would, because of all the added XML roughage. In the original design I also used XML/RPC for the return trip describing the board state, but after this slowness, I decided to try UDP in order to reduce the volume of return network data. The UDP is all packed binary fields with minimal size, unlike XML. This made no difference to the Mac at all; the XP return path seems to suffer from fewer dropouts using UDP than it did from XML/RPC, which is atop TCP, which is supposed to be more relaible than UDP. HA!

Quote:
Definitely some developers code runs very badly on intel based macs, NI stuff tends to use twice the amount of cpu running on OS X as when running XP on my MacBook pro. I Don' know why, code I have written and benchmarked runs slightly slower under OS X, but not much.


I have played with some CPU intensive home benchmarks that show the Mac beating my Alienware. It smells like a synchronization problem, maybe the packet is getting in but not getting handed to a thread in a timely fashion. EDIT: If they have a polling loop deep down in the O.S., that would account for incoming slowness and a CPU jump. Man, would that suck.

1982 was the last time I took a UNIX admin course Exclamation I studiously avoid that kind of thing, but I may have to go digging into low level UNIX land before I am done with this. OSX, look out Exclamation

Thanks again.

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 3868
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Fri Jul 18, 2008 11:48 am    Post subject: Reply with quote  Mark this post and the followings unread

The UDP stuff sounds very strange, when I first read your last post I thought it may be a Nagel problem but this would only add 200ms per packet, what sort of delay are you seeing?

If it is a Nagel problem this will be caused by your sending code, the socket options should be set up with TCP_NODELAY when using small packets like this. Or you should pad out the data sent a bit to a couple of KB, networking is one of the few fields where sending more data can be quicker, especially under microsoft operating systems.
Back to top
View user's profile Send private message
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 20677
Location: The Netherlands, Enschede
Audio files: 156
G2 patch files: 318

PostPosted: Fri Jul 18, 2008 12:05 pm    Post subject: Reply with quote  Mark this post and the followings unread

Nagle Rolling Eyes

But can it even be used for UDP, don't think so ... anyway, a network sniffer might give some info about where the delays occur. (for windows I use Ethersnoop, not ideal but useful).

_________________
Jan
Back to top
View user's profile Send private message Visit poster's website
elektro80
Site Admin


Joined: Mar 25, 2003
Posts: 21977
Location: Norway
Audio files: 14

PostPosted: Fri Jul 18, 2008 12:21 pm    Post subject: Reply with quote  Mark this post and the followings unread

Have you checked you serial number with Apple Support? At least over here in Norway we have seen some MBPs and MBs with serious networking issues. THis is a hardware issue.
_________________
A Charity Pantomime in aid of Paranoid Schizophrenics descended into chaos yesterday when someone shouted, "He's behind you!"

MySpace
SoundCloud
Flickr
Back to top
View user's profile Send private message Visit poster's website
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Fri Jul 18, 2008 12:53 pm    Post subject: Reply with quote  Mark this post and the followings unread

BobTheDog wrote:
The UDP stuff sounds very strange, when I first read your last post I thought it may be a Nagel problem but this would only add 200ms per packet, what sort of delay are you seeing?

If it is a Nagel problem this will be caused by your sending code, the socket options should be set up with TCP_NODELAY when using small packets like this. Or you should pad out the data sent a bit to a couple of KB, networking is one of the few fields where sending more data can be quicker, especially under microsoft operating systems.

The delay runs anywhere from 10 to 30 seconds. It's horrible. The UDP datagrams are being sent from an XP Alienware machine, and if I put a Dell receiver and the Mac receiver side-by-side, the Dell updates its chess display from the UDP datagram "immediately" (from a user perspective), while the Mac takes at least 10 seconds. So this problem can't be the sending side, since the UDP datagrams are obviously getting out.

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Fri Jul 18, 2008 12:55 pm    Post subject: Reply with quote  Mark this post and the followings unread

elektro80 wrote:
Have you checked you serial number with Apple Support? At least over here in Norway we have seen some MBPs and MBs with serious networking issues. THis is a hardware issue.

Thanks. I only started looking at this seriously when I ported the chess program to OSX. EM2008 deadline. Deadlines are always good for forcing problems to the surface. I'll chec on the number.

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
elektro80
Site Admin


Joined: Mar 25, 2003
Posts: 21977
Location: Norway
Audio files: 14

PostPosted: Fri Jul 18, 2008 12:59 pm    Post subject: Reply with quote  Mark this post and the followings unread

Did you do this:
Restart MacBookPro, then press Option-Command-p-r until you hear two start up beeps ?

That´s the NVRAM reset.

_________________
A Charity Pantomime in aid of Paranoid Schizophrenics descended into chaos yesterday when someone shouted, "He's behind you!"

MySpace
SoundCloud
Flickr
Back to top
View user's profile Send private message Visit poster's website
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Fri Jul 18, 2008 1:05 pm    Post subject: Reply with quote  Mark this post and the followings unread

Just looked up Nagle. It wouldn't affect the UDP datagrams carrying the game state, since Nagle is TCP, but, if a player makes a move from the Mac, the UDP datagrams showing the board state are preceded by an XML-RPC-over-TCP calls to make the move and if the XML-RPC return value comes back slowly, the display thread in the Mac won't process the UDP datagram until *after* it gets the XML-RPC-TCP response. I'll give TCP_NODELAY a try on *that* connection.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Fri Jul 18, 2008 1:06 pm    Post subject: Reply with quote  Mark this post and the followings unread

elektro80 wrote:
Did you do this:
Restart MacBookPro, then press Option-Command-p-r until you hear two start up beeps ?

That´s the NVRAM reset.

Is it safe to do? I would imagine so, but this is one of those "Are you sure?" messages!

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
elektro80
Site Admin


Joined: Mar 25, 2003
Posts: 21977
Location: Norway
Audio files: 14

PostPosted: Fri Jul 18, 2008 1:10 pm    Post subject: Reply with quote  Mark this post and the followings unread

Yes, quite safe. Well, unless you have been setting some stuff yourself to the NVRAM and such and you wouldn´t like to have that flushed.. but that I doubt.. Very Happy

The reset is quite OK. You might have to tweak some basic system parameters again.. but those are never of the dangerous or fatal kind.

Trust me. Do it! Very Happy

_________________
A Charity Pantomime in aid of Paranoid Schizophrenics descended into chaos yesterday when someone shouted, "He's behind you!"

MySpace
SoundCloud
Flickr
Back to top
View user's profile Send private message Visit poster's website
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Fri Jul 18, 2008 2:51 pm    Post subject: Reply with quote  Mark this post and the followings unread

Did the Option-Command-p-r, didn't hurt anything Very Happy Still gotta check on that serial number, but

Given the fact that the protocol is:

1. Chess GUI client sends and XML/RPC/TCP call to game server,

2. Game server replies with XML/RPC/TCP result

3. Game server sends individual UDP display updates to all subscribed GUI clients, 1 at a time (I plan to switch to broadcast later)

I set two machines as gui clients of the alienware games server, the mac and a dell, side by side, and took turns making moves from the mac and dell.

When I move from the mac, the dell display updates fast, the mac slow.

When I move from the dell, both the mac and dell update fast.

So, it appears that the mac is not sending out the XML/RPC/TCP call right away. (EDIT: No, that can't be it, otherwise the server wouldn't get the move from the Mac. It's gotta be that the Aleinware responds faster to the Dell than the Mac with the XMLRPC response for some reason!) When the mac does not get involved in making an XML/RPC/TCP call, it is as fast as the dell. The slows have nothing to do with the UDP display update datagrams.

Have not found a way to config a TCP_NODELAY on an XML/RPC client, but I did find this:
Quote:
Nagling: by default, sockets in unix try to bunch up data into larger packets, to avoid congestion problems. This can result in delays in sending XMLRPC requests. Smart implementations of XMLRPC set TCP_NODELAY (or TCP_CORK); for example, Xmlrpc-C does this. The python xmlrpclib does not. Ultimately the workaround is to submit a patch for xmlrpclib.py to turn on TCP_NODELAY for the socket, or otherwise flush the socket.

I am using Python xmlrpclib, and so far I see no evidence that this was fixed. The above was written last month!!! xmlrpclib hides the underlying socket; haven't found it yet.

So, I guess the options are to shove some extra long parameter into the XML/RPC calls and return value, or else rewrite from XML/RPC to something else, probably UDP. Grumble, grumble. Rolling my own RCP-over-UDP won't be so bad in Python, since I can just pass the whole thing as a string and "eval()" it on the other side. It would be nice if reuse was so simple as to actually work.

Thanks for the help!

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 3868
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Sat Jul 19, 2008 1:10 am    Post subject: Reply with quote  Mark this post and the followings unread

Blue Hell wrote:
Nagle Rolling Eyes

But can it even be used for UDP, don't think so ... anyway, a network sniffer might give some info about where the delays occur. (for windows I use Ethersnoop, not ideal but useful).


No it isn't, thats why I was confused!

The misspelling is of course just stupidity Embarassed

Andy
Back to top
View user's profile Send private message
BobTheDog



Joined: Feb 28, 2005
Posts: 3868
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Sat Jul 19, 2008 1:16 am    Post subject: Reply with quote  Mark this post and the followings unread

Acoustic Interloper wrote:
BobTheDog wrote:
The UDP stuff sounds very strange, when I first read your last post I thought it may be a Nagel problem but this would only add 200ms per packet, what sort of delay are you seeing?

If it is a Nagel problem this will be caused by your sending code, the socket options should be set up with TCP_NODELAY when using small packets like this. Or you should pad out the data sent a bit to a couple of KB, networking is one of the few fields where sending more data can be quicker, especially under microsoft operating systems.

The delay runs anywhere from 10 to 30 seconds. It's horrible. The UDP datagrams are being sent from an XP Alienware machine, and if I put a Dell receiver and the Mac receiver side-by-side, the Dell updates its chess display from the UDP datagram "immediately" (from a user perspective), while the Mac takes at least 10 seconds. So this problem can't be the sending side, since the UDP datagrams are obviously getting out.


10-30 seconds looks like it may be a retransmit problem, maybe a sniffer is the way to go on this.
Back to top
View user's profile Send private message
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Sat Jul 19, 2008 1:55 pm    Post subject: Reply with quote  Mark this post and the followings unread

The chess game problem was definitely in the XML-RPC/TCP code, could have been Nagel inside of Python's XML-RPC library (where I can't get at the socket to TCP_NODELAY it), or it could have been problems with Python's XML-RPC library on the Mac. I just rewrote it to get rid of XML-RPC and am using all UDP datagrams instead. Occasionally a UDP datagram gets lost, but clicking the "redisplay" button widget fixes that. Good enough for EM2008.

Apparently my other mac issues are unrelated to this, unless they are TCP generic problems. But that Python XML-RPC library is certainly suspect.

Now, my fast Alienware machine has developed a vertical scar in its display. Had the video card replaced about a year ago. Hope this one isn't dying. Why must these things happen right before I finally get out of the house to play something? Looks like I better hurry up and port the rest of my stuff to the Mac laptop. I may be back with more questions Surprised

I think one reason that people get into the this-OS-camp vs. that-OS-camp is not the OS, but because the apps don't exist or they are hard to port or the libraries work one way on one platform and another way on another. So, once you get used to the pains of your favorite platform, you are loathe to change. I don't have a favorite any more. I'd like a small footprint RTOS with a lot of DSPs on the side, with all the MSP/ChucK/SC libraries available on those DSPs. Of course, I also like to write software that other people can use, so I guess that leaves out special platforms.

I'm going to spend the evening restringing 2 banjos and 2 Appalachian dulcimers. Maybe I can even con my wife into playing one of those.

Thanks for your help!

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 3868
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Sat Jul 19, 2008 2:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

Acoustic Interloper wrote:
I think one reason that people get into the this-OS-camp vs. that-OS-camp is not the OS, but because the apps don't exist or they are hard to port or the libraries work one way on one platform and another way on another. So, once you get used to the pains of your favorite platform, you are loathe to change.


Well I work on code that has to run on Irix, various Linux dists (32 and 64 bit versions), XP and 2003 server (32 and 64 bit versions) also covering little and big endian architecture, running over multiple processors and in clustered environments.

I have begun to hate all computers and operating systems!
Back to top
View user's profile Send private message
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Tue Jul 22, 2008 11:32 am    Post subject: Re: Help! My MacBook Pro is suffering from Arrested Development
Subject description: Incoming network is spastic and Chuck makes snap, crackle and pop
Reply with quote  Mark this post and the followings unread

Acoustic Interloper wrote:
The other problem is that I tested a ChucK application that works fine on the Alienware machine on the MacBook, and on the Mac I get a lot of crackly noise that I don't get on the Alienware. Same Edirol sound box, same sampling rate. I tried playing with the buffers sizes, and also tried the Mac's built-in sound card, on the chance that the Mac Edirol driver is goofy, but still have the crackles. The machines are on par CPU and memory wise, about 3.5 GHz and 2 GB ram, and run the ChucK app in the mix with about a 30% CPU load, which should be fine.

Healed this one by using a combination of ChucK's blocking configuration, an undocumented command line arg (at least I haven't found documentation for it), with expanded buffersize, which I had tried without blocking before. I assume blocking waits until the output audio buffer is flushed before continuing. These adjustments probably add latency, but for the chess game-to-music this does not matter, since the temporal correlation of a chess move to music changes is not near as tight as banjo finger picking speed.

Next I have to rewrite a MIDI foot controller-driven state machine from Tcl+a custom MIDI library to ChucK to get it to work on Mac, and I think I'll be set for EM2008.

No common thread to these problems, other than that porting is a pain. At least I am getting some time with my Mac. Razz

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Wed Jul 23, 2008 1:13 pm    Post subject: Reply with quote  Mark this post and the followings unread

Here's a cute portability problem:
Quote:
$ python
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> help("time.clock")
Help on built-in function clock in time:

time.clock = clock(...)
clock() -> floating point number

Return the CPU time or real time since the start of the process or since
the first call to clock(). This has as much precision as the system
records.

>>>

CPU time or wall clock time Shocked Now there's a handy time bomb, so to speak. Almost needless to say, it works one way on XP, and the other on OSX.

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 20677
Location: The Netherlands, Enschede
Audio files: 156
G2 patch files: 318

PostPosted: Wed Jul 23, 2008 2:17 pm    Post subject: Reply with quote  Mark this post and the followings unread

http://www.daniweb.com/code/snippet218.html suggests that time.time() might be more compatible.
_________________
Jan
Back to top
View user's profile Send private message Visit poster's website
Acoustic Interloper



Joined: Jul 07, 2007
Posts: 1657
Location: Berks County, PA
Audio files: 38

PostPosted: Wed Jul 23, 2008 2:50 pm    Post subject: Reply with quote  Mark this post and the followings unread

Blue Hell wrote:
http://www.daniweb.com/code/snippet218.html suggests that time.time() might be more compatible.

Thanks, yep, that's what I started using yesterday. That may be vulnerable to the Unix Millennium bug, but it should be OK for the chess game.

_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Back to top
View user's profile Send private message Visit poster's website
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 20677
Location: The Netherlands, Enschede
Audio files: 156
G2 patch files: 318

PostPosted: Wed Jul 23, 2008 3:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

All my embedded code has the 2038 limit, but hell, I'd be over 80 years old by that time Shocked Dunno all my devices are built with a life expectancy of 10 years and they don't have to deal with time beyond "tomorrow". Long before the date gets to be a problem the eeproms and flash memories will be worn out and obsolete.
_________________
Jan
Back to top
View user's profile Send private message Visit poster's website
BobTheDog



Joined: Feb 28, 2005
Posts: 3868
Location: England
Audio files: 32
G2 patch files: 15

PostPosted: Thu Jul 24, 2008 2:10 am    Post subject: Reply with quote  Mark this post and the followings unread

You could always use the Hi resolution timers.

Windows - QueryPerformanceCounter()

Unix/linux etc - clock_gettime()


You should be able to get at these somehow, c++ code :

Code:


#ifndef  HiResTimer_H
#define HiResTimer_H
#include "HLMObject.h"

#ifdef WIN32
#include "windows.h"
#else
#include <stdio>
#include <time>
#include <errno>
#define NUM_NANO 1000000000
#endif

//inline HI Resolution timer

namespace SMG
{
namespace HLM
{

class HiResTimer  : public HLMObject
{
 public:
  HiResTimer()
    {
#ifdef WIN32
      m_bInitialised = (QueryPerformanceFrequency( (LARGE_INTEGER *)&m_Frequency ) != 0);
      start();
#else
      if (clock_getres(CLOCK_THREAD_CPUTIME_ID, &tRes))
            LOG(HLM::Log::ssHLM, HLM::Log::llVerbose, "Problem getting the timer resolution. System errno: %d \n", oserror());
         else
            m_bInitialised = 1;
      start();     
#endif
    }
 
  virtual ~HiResTimer()
    {
    }

  void start(void)
    {
#ifdef WIN32
      QueryPerformanceCounter( (LARGE_INTEGER *)&m_Time );
#else
      if (clock_gettime(CLOCK_THREAD_CPUTIME_ID, &tStart))
         LOG(HLM::Log::ssHLM, HLM::Log::llVerbose, "Problem getting the timer information. System errno: %d \n", oserror());
#endif
    }

   float getElapsedMS(void)
   {
#ifdef WIN32
      if (m_bInitialised)
         {
            m_LastTime = m_Time;
            QueryPerformanceCounter( (LARGE_INTEGER *)&m_Time );
            m_ElapsedTime = m_Time - m_LastTime;

            return ((float)m_ElapsedTime / (float)m_Frequency)  * 1000.0f;
         }
      else
            return (0.0f);
#else
      if (m_bInitialised)
         {
            if (clock_gettime(CLOCK_THREAD_CPUTIME_ID, &tEnd))
               LOG(HLM::Log::ssHLM, HLM::Log::llVerbose, "Problem getting the timer information. System errno: %d \n", oserror());

            long temp1 = (tEnd.tv_sec - tStart.tv_sec );
            long temp2 = (tEnd.tv_nsec - tStart.tv_nsec );
            start();
            return  ((float)(temp1 * NUM_NANO) + temp2) / 1000000;
         }
         else
            return(0.0f);
#endif
   }

   float getElapsedSecs(void)
   {
#ifdef WIN32
      if (m_bInitialised)
      {
         m_LastTime = m_Time;
         QueryPerformanceCounter( (LARGE_INTEGER *)&m_Time );
         m_ElapsedTime = m_Time - m_LastTime;
    
         return ((float)m_ElapsedTime / (float)m_Frequency);
      }
    else
         return (0.0f);
#else
   if (m_bInitialised)
   {
      if (clock_gettime(CLOCK_THREAD_CPUTIME_ID, &tEnd))
         LOG(HLM::Log::ssHLM, HLM::Log::llVerbose, "Problem getting the timer information. System errno: %d \n", oserror());
      long temp1 = (tEnd.tv_sec - tStart.tv_sec );
      long temp2 = (tEnd.tv_nsec - tStart.tv_nsec );
      start();
      return ((float)(temp1 * NUM_NANO) + temp2) / NUM_NANO;
   }
   else
      return(0.0f);
#endif
   }

private:
  bool   m_bInitialised;

#ifdef WIN32
  __int64 m_Frequency;
  __int64 m_Time;
  __int64 m_LastTime;
  __int64 m_ElapsedTime;
#else
  timespec tStart;
  timespec tEnd;
  timespec tRes;
#endif

};

}

}
#endif
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Moderators: elektro80
Page 1 of 1 [23 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » Instruments and Equipment » OSX as a music workstation
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use