>> audio applications typically use SCHED_FIFO. however they are >> rate-monotonic by design, so i wanted to evaluate how SCHED_DEADLINE >> behaves here. > > Right. Exactly what I started to think about lately as well. > >> >>> Asking because we might want to have a look at how to relax the current >>> privileges requirement. >> >> please :) > > Anything to try attracting new users. :-P > > More seriously, could you please describe in a bit more details your > specific use case? Based on JACK I guess? Is it the application you are > interested into public available somewhere? it could be based on JACK or natively on ALSA. furthermore the fun part starts when trying to distribute work to multiple threads: during the time slice of one audio callback (could be as low as 1.3ms), we need to wake helper threads and (busy?)wait to collect all the results. (while one of the applications is open source, it's not entirely straight-forward to use) for me it's more an investigation if SCHED_DEADLINE is actually feasible in real-world audio application these days. tommaso used to have a research prototype [1], built directly into JACK. however currently i'd be more interested in using it in ALSA. but yeah, it's more an investigation as SCHED_FIFO does a decent job for my use case ... cheers, tim [1] http://retis.sssup.it/~tommaso/publications/LAC-2011.pdf
Attachment:
signature.asc
Description: OpenPGP digital signature
