one step closer to working vbap panning

[ardour.git] / libs / ardour / ardour / cycles.h

diff --git a/libs/ardour/ardour/cycles.h b/libs/ardour/ardour/cycles.h
index 0d1ac154dde746a474cefd3c00e8b78c6ad232d5..9f6d9b4b5c3ed1837414588a34c7e2a151c2e3b9 100644 (file)
--- a/libs/ardour/ardour/cycles.h
+++ b/libs/ardour/ardour/cycles.h
@@ -1,7 +1,7 @@
 /*
     Copyright (C) 2001 Paul Davis
     Code derived from various headers from the Linux kernel
-    
+
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
     the Free Software Foundation; either version 2 of the License, or
@@ -37,7 +37,7 @@
  * We only use the low 32 bits, and we'd simply better make sure
  * that we reschedule before that wraps. Scheduling at least every
  * four billion cycles just basically sounds like a good idea,
- * regardless of how fast the machine is. 
+ * regardless of how fast the machine is.
  */
 typedef uint64_t cycles_t;
 
@@ -48,10 +48,10 @@ extern cycles_t cacheflush_time;
 
 static inline cycles_t get_cycles (void)
 {
-       uint32_t long ret;
+       cycles_t ret;
 
        rdtscll(ret);
-       return ret;
+       return ret & 0xffffffff;
 }
 
 #elif defined(__powerpc__)
@@ -103,7 +103,7 @@ get_cycles (void)
  * Standard way to access the cycle counter.
  * Currently only used on SMP for scheduling.
  *
- * Only the low 32 bits are available as a continuously counting entity. 
+ * Only the low 32 bits are available as a continuously counting entity.
  * But this only means we'll force a reschedule every 8 seconds or so,
  * which isn't an evil thing.
  */