sound driver for RTAI

[Jan Kiszka]

Jan Kiszka wrote:
> ...
> I also think I can explain it: while magma only schedules a timeout when 
> the task actually calls rt_task_wait_period(), fusion continues to run 
> the periodic thread timer and increments an overflow counter each round 
> [1]. On rt_task_wait_period(), the counter is decremented, thus every 
> overrun is detected [2]. In contrast, magma is lacking any overrun 
> detection in rt_task_wait_period(): only too small periods or resync 

Correction 1: there *is* an overrun detection. I missed that rt_time_h 
is not a constant but gets updated on every timer tick:

http://www.rts.uni-hannover.de/rtai/lxr/source/base/sched/sched.c?v=cvs-3.x-magma#L1079

Anyway, this does not seem to work reliably when the period is close to 
the system's critical frequency (is rt_half_tick too large here?), 
otherwise, more misses should have been detected. Grr, I'm still lacking 
the missing piece in this puzzle, likely as I'm not that used to reading 
RTAI/classic scheduler code anymore.

> requests (issued by the watchdog) with cause it to return a non-zero 
> error code [3]. What you get with magma are also sporadic overruns (less 
> frequently than with fusion at that rate), but they are not 

Correction 2: we cannot say anything about the frequency of deadline 
misses, we can only say that the critical frequency you can run a task 
with magma without any overruns is larger than for fusion in this 
particular case.

What would be interesting now is A) to detect the overruns in the 
latency tool, and B) to let fusion run over non-threaded Adeos (closer 
to the immed mode). According to Philippe, this should work now, but I 
also did not dare to test it yet... :)

Jan