On 18/08/18 15:26, Tim Blechmann wrote: > >> 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 ... I (almost) see. Thanks for the details. > [1] http://retis.sssup.it/~tommaso/publications/LAC-2011.pdf So, this was IIRC using AQuoSA hierarchical RT on EDF scheduler implementation; which it was handy to easy the task of assigning CBS server parameters to JACK clients (graph). In your case - assuming you could already use DEADLINE for !root - do you think you would need to use the same interface for the multiple threads you are distributing work among? Or would you be fine with assigning runtime/deadline for each one of those? BTW, cc-ing Tommaso and Luca. Discussion started from https://www.spinics.net/lists/linux-rt-users/msg19296.html
