Hi all, i just noticed that in m_sched.c the value of sys_sleepgrain is always the same (5000 = 5ms), no matter which amount of latency i specified in the audio settings. This seems to be that way because the value of sys_sleepgrain is initialized when the scheduler is started and is not updated afterwards. Could be the cause of some latency-related troubles, or am i overlooking something?
best greetings, Thomas
hi thomas ...
i just noticed that in m_sched.c the value of sys_sleepgrain is always the same (5000 = 5ms), no matter which amount of latency i specified in the audio settings. This seems to be that way because the value of sys_sleepgrain is initialized when the scheduler is started and is not updated afterwards. Could be the cause of some latency-related troubles, or am i overlooking something?
wow, you're right ... sys_open_audio only sets the sys_schedadvance, but no the sys_sleepgrain. they should be closely related, though ... especially when having low latencies ... i think, this is the reason, why no audio api, except for the native asio with callback-based dsp scheduling can achieve very good latencies!
cheers ... tim
On Wed, 2 Feb 2005, Thomas Grill wrote:
Hi all, i just noticed that in m_sched.c the value of sys_sleepgrain is always the same (5000 = 5ms), no matter which amount of latency i specified in the audio settings. This seems to be that way because the value of sys_sleepgrain is initialized when the scheduler is started and is not updated afterwards. Could be the cause of some latency-related troubles, or am i overlooking something?
Looks like a bug. I never fully understood the usage of sleep in the pd scheduler, because sleep timer resolution is never smaller than 10 ms under Linux. Thats why pd under linux always did blocking read/writes, using the soundcard as a timer.
Not sure if this is still true and how the timers on other operating systems behave, but if they behave similar then it doesn't matter if you set the the sleepgrain to 1 or 5 ms, it will always sleep 10.
Guenter
best greetings, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Looks like a bug. I never fully understood the usage of sleep in the pd scheduler, because sleep timer resolution is never smaller than 10 ms under Linux. Thats why pd under linux always did blocking read/writes, using the soundcard as a timer.
But if this were the case, doesn't that mean that message processing would have a granularity of 10 ms? Or, under linux, does it never really sleep, because the DACs "have slept"?
greetings, Thomas
On Sun, 6 Feb 2005, Thomas Grill wrote:
Looks like a bug. I never fully understood the usage of sleep in the pd scheduler, because sleep timer resolution is never smaller than 10 ms under Linux. Thats why pd under linux always did blocking read/writes, using the soundcard as a timer.
But if this were the case, doesn't that mean that message processing would have a granularity of 10 ms? Or, under linux, does it never really sleep, because the DACs "have slept"?
The granularity is not affected by the timing, as the granularity depends on when the messages are processed, every dac block. It affects how events from the outside arrive, though, like mouse, keyboard or MIDI.
As the pd scheduler is one thread only, it doesn't matter so much where the system is sleeping, in the audio I/O or somewhere else.
Anyhow, I am pretty sure that there is still a lot room for improvement in Pd's timing.
Guenter
greetings, Thomas
-
g�nter geiger -
Thomas Grill -
Tim Blechmann