[Portaudio] Allow tweaking PA callback thread scheduler and priority

Ross Bencina rossb-lists at audiomulch.com
Sun Mar 20 20:04:16 EDT 2016

Hi Alan, Markus,

I don't know anything about common practice with RT thread scheduling 
for ALSA, but my recommendation from a PA API behavior perspective would be:

- Don't extend PaAlsa_EnableRealtimeScheduling(), just use it for 
enable/disable. Choose the best default thread parameters for people who 
don't want fine-grained selection (ie people with no other RT threads). 
PortAudio should reflect best practice in the ALSA world. If you don't 
know what the best-practice thread parameters are, ask on the ALSA list: 
"what is the recommended real-time scheduling parameters for an ALSA 
thread?". My dim recollection is that SCHED_FIFO may be correct, not 
sure about priority.

- Add a new function PaAlsa_SetRealtimeSchedulingParameters(stream, 
policy, priority) for people who want fine grained tuning.

- Having #defines in the code is good practice, but they should not be 
the primary interface for configuring thread priorities. They should 
only be used for setting defaults, ie:




On 21/03/2016 5:02 AM, Alan Horstmann wrote:
> Hi Markus,
> Thanks for posting your changes.  It is probably me that needs to pick this
> up, though I am not expert in thread scheduling and priorities.  So I've done
> a little background reading...
> On Saturday 19 March 2016 17:15, Markus Svilans wrote:
>> Recently I was working on an embedded Linux project, with several
>> threads at various SCHED_RR and SCHED_FIFO priorities. I found that the
>> PortAudio stream was getting interrupted with overflows and underflows
>> now and then, because PA callback thread was getting pre-empted by other
>> threads. The default PortAudio real-time scheduling was being set to
>> SCHED_FIFO at a priority of 1.
>> To work around the issue, I changed the PortAudio callback thread to use
>> the SCHED_RR scheduler and the highest priority. Now the audio stream
>> does not get interrupted. The attached patch shows what I did. It is
>> based on code from PortAudio SVN rev 1919
>>From my limited reading, I would have thought SCHED_FIFO would have been
> correct, but indeed the priority of 1 does look rather low, and the comment:
> "/* Priority should only matter between contending FIFO threads? */"
> looks bogus?  IIUC priority is the primary selector, and policy only
> influences the choice between threads of equal priority?  SCHED_RR would mean
> that thread gets a limited time-chunk whereas _FIFO means it will be always
> allowed to complete (once it gets a turn)?
>> With the patch, you can control the callback thread scheduler and
>> priority using two #defines:
>> I set the defaults to SCHED_RR and sched_get_priority_max(SCHED_RR),
>> respectively.
> Did you try simply:
> spm.sched_priority = sched_get_priority_max(SCHED_FIFO);
> as I would have expected that to be equally, or more, effective?
> Maybe 'PaAlsa_EnableRealtimeScheduling()' should interpret the value given as
> a rough 0-9 priority setting rather than just an 'int-bool'?  With '9'
> setting _priority_max() and the other values scaled approximately, but it's
> just a quick idea.
> Regards
> Alan
>> As a side not, if you want real-time scheduling for your PA callbacks,
>> don't forget to activate real-time scheduling on your audio stream:
>> #include <pa_linux_alsa.h>
>> ...
>> PaStream *stream;
>> ...
>> // initialize audio stream etc. etc.
>> ...
>> PaAlsa_EnableRealtimeScheduling(stream, 1);
>> ...
>> // start audio stream
>> This patch hard-codes the scheduler options, but in the future people
>> might find it useful to add these properties to the PaStream struct, so
>> they can be tweaked at runtime and/or on an OS specific basis.
>> Thank you and best wishes,
>> Markus
> _______________________________________________
> Portaudio mailing list
> Portaudio at lists.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/portaudio

More information about the Portaudio mailing list