>>>> main audio thread: >>>> while running: >>>> snd_pcm_read // blocks until data is delivered from ALSA >>>> wake helper(s) >>>> do work() >>>> sync_with_helper(s) >>>> snd_pcm_write // blocks until data is delivered to ALSA >>>> >>>> alsa is basically driven by the hardware, which delivers/requests data >>>> every ~1.3ms. >> >>>> distributing the work is a little tricky: to avoid excessive scheduling >>>> overhead, the worker threads are typically woken up (after snd_pcm_read) >>>> and the result is collected where sync_with_helper() typically boils >>>> down to busy waiting. in this case, the workers as rate-monotonic in a >>>> similar manner as the main audio thread. >>> >>> When you say "rate-monitonic", do you mean that the worker threads with >>> smaller period (high rate, so) have a higher fixed-priority? If so, what >>> are the other periods? >> >> the period will be the same period: i wake up the workers once per >> period of the main thread, distribute the work and collect it at the >> end. so "period" is basically the same, "runtime" a little lower. > > Good! Nerdy comment: In the theory, they use/we the term > "rate-monotonic", in a very specific sense. It is a method to assign > priority to tasks in a task-level fixed-priority scheduler (like FIFO). > The tasks with shorter period will receive a higher priority. So I think > that you meant that: > > "the workers are _periodic_ in a similar manner as the main audio thread." > > right? am I missing something? > > (well, if all tasks have the same period, they can have the same > priority in the rate-monotonic assignment, but in deadline-monotonic as > well (iff D=P)... so it is not the most precise term.) yes, all threads have the same period (e.g. 64 audio frames at 48000hz, ~1.33ms). the workers may have a slightly earlier deadline as the main thread (as the main thread needs to deliver the computed results to the driver, but that's probably a minor detail). >>> So, your main wish here is to avoid having a watchdog thread to >>> "throttle" misbehaving workload/setup? >> >> mainly ... and nerdy research if SCHED_DEADLINE is useful for audio >> applications ... ;) >> >> >>> For curiosity, what are the "time-constraints" setup used on mach? >> >> it's pretty similar to the SCHED_DEADLINE constraints: >> >> from: >> https://opensource.apple.com/source/xnu/xnu-124.7/osfmk/mach/thread_policy.h.auto.html > > Nice, indeed very similar. So, it seems that the only thing we are > missing is !root for your use-case, right? > > (/me wishes he could see peterz face now) the mach API also has this notion of "period == 0", but apart from that it's quite similar. apart from that, i'm only missing two features: * using SCHED_DEADLINE from user applications is kind of a showstopper for me * a nicer glibc wrapper, that allows me to use pthreads rather than using `syscall`: it's all pretty easy to obtain the `tid` for a calling thread (gettid), but it seems to be impossible to obtain the `tid` from `pthread_t` without some hacks which are way too dirty to share in public ... cheers, tim
Attachment:
signature.asc
Description: OpenPGP digital signature
