Re: [Alsa-devel] double buffer xruns

[Paul Davis]

I am wanting to know wether there is some way I can get rid of these  1ms
XRuns ?

if they are not caused by your application's design (i haven't looked
at it closely), then the answer is no, at least not without:

   1) running it SCHED_FIFO, with mlockall() called
   2) running a low-latency patched kernel

there are many places in the standard linux kernel where execution of
a thread that is ready to run can be delayed, in some cases by up to 100ms.
there is no workaround for this without the two steps i mentioned above.

--p

___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] double buffer xruns

[Paul Davis]

I am wanting to know wether there is some way I can get rid of these  1ms
XRuns ?

do note, hwoever, that it could easily be your application desing that
is the problem.

this:

while ((frameCount=dd-audio.readAudio())  dd-audio.active){
   int written;
written=snd_pcm_writei(dd-pcm,
   (*dd-audio.windows.current())[0],
   frameCount);

  if (written == -EAGAIN || written = 0) {
   snd_pcm_wait(dd-pcm, 1000);

is a rather unusual design, and one that may not work reliably. 

i suspect that you may not be writing chunks of the correct size to
the PCM device. by delaying for 1000msecs when you have no idea what
the amount of data that could not written, you are pretty much
ensuring that xruns will happen from time to time.

--p

___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] double buffer xruns

[Paul Davis]

i suspect that you may not be writing chunks of the correct size to
the PCM device. by delaying for 1000msecs when you have no idea what

sorry, i was forgetting what snd_pcm_wait() did. even so, this is
still a design that could cause problems, i think.

--p


___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel