Clock_nanosleep（）尚不支持CLOCK_MONOTONIC_RAW。 怎么处理这个？
目前在Debian Jessie上使用CLOCK_MONOTONIC_RAW的clock_nanosleep返回EOPNOTSUPP。
如何解决问题并补偿可能在定时器循环中应用于CLOCK_MONOTONIC的NTP调整？
clock_nanosleep本身是否也受到NTP调整的影响？ 如果在睡觉时进行调整， clock_nanosleep睡眠时间会更长吗？
在我的特定情况下，我是否应该担心可能的CLOCK_MONOTONIC NTP调整？ 考虑到我的代码将在没有实时时钟的系统上运行并且可能不时丢失Internet连接，NTP应用于CLOCK_MONOTONIC的最大可能“时间跳转”是什么？
长话故事。 我正在使用一个简单的循环模拟音频文件播放，我需要保持一致的播放位置。
带有TIMER_ABSTIME标志的clock_nanosleep似乎正在完成工作，但我不确定CLOCK_MONOTONIC是否足以避免播放位置的明显跳跃。
这是我正在使用的代码：
clock_gettime(CLOCK_MONOTONIC, &deadline); // run until asked to stop while(!need_quit(stop_mutex_signal)) { // do stuff ... // add time ms to previous deadline deadline.tv_nsec += device->periodTime * NANOSECONDS_PER_MILLISEC; // normalize the time to account for the second boundary if(deadline.tv_nsec >= NANOSECONDS_PER_SEC) { deadline.tv_nsec -= NANOSECONDS_PER_SEC; deadline.tv_sec++; } if(clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &deadline, NULL) != 0) { // something happened - error or exit signal, cannot continue return; } }
我很好奇，为什么还没有实现clock_nanosleep中对CLOCK_MONOTONIC_RAW的支持？ 这是否意味着CLOCK_MONOTONIC足以满足大多数情况，即使是音频/video同步？
CLOCK_MONOTONIC是单调的。 从ntp或其他方面来看，它不受任何跳跃的影响。 它唯一受制于漂移率调整，通常由ntpd通过adjtime或类似的方式完成。 对于短暂的间隔，这种调整根本不可见。 在任何情况下，只要您的系统没有恶意配置，它就比CLOCK_MONOTONIC_RAW 准确得多。 作为一个例子（组成数字，但它们可能在合理范围内） CLOCK_MONOTONIC_RAW可能以每实际秒999950000纳秒的速率运行， CLOCK_MONOTONIC以每实际秒1000001000纳秒的速率运行。