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

David García Garzón dgarcia at iua.upf.edu
Tue Mar 13 13:09:29 PDT 2007


On Tuesday 13 March 2007 15:15:08 Bjorn Roche wrote:
> On Mar 12, 2007, at 3:27 PM, David García Garzón wrote:
> > Hi, all.
> >
> > We are trying to use Portaudio as the default audio backend for
> > CLAM. We
> > already used it on Windows and got some xruns depending on the
> > machine, but
> > for Linux we got a lot of continuous xruns either by using OSS api
> > (not
> > reported to the callback but heard) and Alsa api (reported and
> > heard). I
> > tested it in several Kubuntu machines. And got the same bad results.
> >
> > Such xruns don't happen neither by using directly JACK or by using
> > Alsa in
> > blocking mode. For direct Alsa, we gave some priority to the audio
> > thread.
> > Maybe that could be the trick but firstly i don't know how the
> > proper way of
> > bumping the portaudio callback priority, and, secondly it is
> > strange for me
> > that portaudio doesn't work well as is.
>
> That is strange. I don't really have an answer (Arve?) but in the
> meantime, the way I boost priority is to do it manually the first
> time the callback is called. This allows me tight control over
> permissions, which is good, but I don't think this is the preferred
> method. (I vaguely recall that setting the app SUID root or with high
> priority permissions or something, it will do this automatically, but
> I can't find that documented on the site -- perhaps searching the
> mailing list archives are required at this point. Obviously, setting
> your app SUID root has security implications, so something different
> would be better.)
>
> If someone wanted to do a quick explanation of the RIGHT way to boost
> the priority, I'd be happy to post it on the wiki.

In my case I just took the following lines from the old native (blocking 
alsa/directx + thread) code and pasted it into the callback:

if (mNeedsPriority) // is set to true before starting the stream
{
mNeedsPriority = false;
#ifdef WIN32
BOOL res;
DWORD err;
res = SetPriorityClass(GetCurrentProcess(),NORMAL_PRIORITY_CLASS );
err = GetLastError();
res = SetThreadPriority( GetCurrentThread(), THREAD_PRIORITY_NORMAL );
err = GetLastError();
#else
struct sched_param sched_param;
int policy;
if (pthread_getschedparam(pthread_self(), &policy, &sched_param) < 0)
   std::cerr << "Scheduler getparam failed..." << std::endl;
sched_param.sched_priority = sched_get_priority_max(SCHED_RR)-1;
if (!pthread_setschedparam(pthread_self(), SCHED_RR, &sched_param))
   std::cerr << "Scheduler set to Round Robin with priority "<< 
sched_param.sched_priority << std::endl;
#endif
}

Although it has solved the xrun problem on some of the pc's still have a 
different kind of xrun. That is instead of continuos short xruns, it does 
long haltings and then audio bursts when i try to use the duplex mode.

Let me try it further and i could give more details.

David.




More information about the clam-devel mailing list