[Clam-devel] Re: [Portaudio] Xruns using alsa api

Arve Knudsen aknuds-1 at broadpark.no
Fri Mar 16 14:15:39 PDT 2007

On Fri, 16 Mar 2007 01:26:19 +0100, David García Garzón  
<dgarcia at iua.upf.edu> wrote:

> On Dijous 15 Març 2007, Arve Knudsen wrote:
>> On Thu, 15 Mar 2007 09:42:29 +0100, David García Garzón
>> <dgarcia at iua.upf.edu> wrote:
>> > I already solved the main xrun problem by boosting the audio thread
>> > priority
>> > the first time the callback is called after starting the stream. I  
>> sent
>> > on a
>> > previous mail the code i used (win32+posix). Putting that code on the
>> > callback is akward. Doing such boost within Portaudio could be more
>> > smart. Is
>> > it convenient? which could be the convenient way to let the user
>> > controlling
>> > that?
>> Actually there is a PA ALSA extension called
>> PaAlsa_EnableRealTimeScheduling (declared in pa_linux_alsa.h). You may
>> want to play with this.
>> Arve
> Yep! that was what i was looking for! If that works i'd rather prefer  
> this
> than the code i already added.
> Any example/documentation on how to use such extensions? When should it  
> be
> called? What is the PaAlsa_EnableWatchdog about?

I don't know how I managed to not see this yesterday, but it turns out  
that in the process of refactoring the threading logic, realtime  
scheduling support had been omitted. I've reenabled it in my latest PA  
checkin however.  Using PaAlsa_EnableRealtimeScheduling is really basic,  
just specify 1 to turn on FIFO thread scheduling when starting a thread or  
0 to use normal scheduling. EnableWatchDog's purpose is to enable/disable  
a watchdog thread of higher priority which shuts down the realtime audio  
thread if it appears stuck. For simplicity's sake I haven't ported that to  
the new code (common Unix threading infrastructure) however, since I don't  
want to spend too much time making porting/debugging.

> Any equivalent extension to boost priority on windows API's? I found the  
> macro
> paWinMmeUseLowLevelLatencyParameters, How to use it? i confess not  
> knowing
> the real api windows chooses by default (mme? ds? asio?). The main  
> reason for
> us to use portaudio is abstracting from the platform and avoiding ifdefs  
> on
> our code.

I suspect Ross enables realtime scheduling by default in PA MME?


More information about the clam-devel mailing list