Fwd: Overrun Errors - SAM9G

Fwd: Overrun Errors - SAM9G

[Akshay Mishra]

Hello,
    I am trying a simple alsa capture on the Atmel ARM9 (SAM9G45). While
only capture runs fine, putting any os call on the same thread gives XRUNs.

Even a innocent usleep(1) seems to lead to regular XRUNs. Eventually I want
to dump this capture on the serial port and I am not able to get past this.

I have tried on AT91 linux as well as on kernel 3.10.10-rt7 with no success.

Please advice,
Akshay

Re: Overrun Errors - SAM9G

[Akshay Mishra]

On 17 July 2014 18:24, Akshay Mishra <akshaymishra@gmail.com> wrote:

> Hello,
>     I am trying a simple alsa capture on the Atmel ARM9 (SAM9G45). While
> only capture runs fine, putting any os call on the same thread gives XRUNs.
>
> Even a innocent usleep(1) seems to lead to regular XRUNs. Eventually I
> want to dump this capture on the serial port and I am not able to get past
> this.
>
>
running pulseaudio gives me the following. I am not sure if this is related.

 snd_pcm_avail() returned a value that is exceptionally large: 414168 bytes
(2347 ms).
E: [alsa-sink] alsa-util.c: Most likely this is a bug in the ALSA driver
'(null)'. Please report this issue to the ALSA developers.
E: [alsa-sink] alsa-util.c: snd_pcm_dump():
E: [alsa-sink] alsa-util.c: Hardware PCM card 0 'Atmel AC97C' device 0
subdevice 0
E: [alsa-sink] alsa-util.c: Its setup is:
E: [alsa-sink] alsa-util.c:   stream       : PLAYBACK
E: [alsa-sink] alsa-util.c:   access       : MMAP_INTERLEAVED
E: [alsa-sink] alsa-util.c:   format       : S16_LE
E: [alsa-sink] alsa-util.c:   subformat    : STD
E: [alsa-sink] alsa-util.c:   channels     : 2
E: [alsa-sink] alsa-util.c:   rate         : 44100
E: [alsa-sink] alsa-util.c:   exact rate   : 44100 (44100/1)
E: [alsa-sink] alsa-util.c:   msbits       : 16
E: [alsa-sink] alsa-util.c:   buffer_size  : 8640
E: [alsa-sink] alsa-util.c:   period_size  : 1440
E: [alsa-sink] alsa-util.c:   period_time  : 32653
E: [alsa-sink] alsa-util.c:   tstamp_mode  : ENABLE
E: [alsa-sink] alsa-util.c:   period_step  : 1
E: [alsa-sink] alsa-util.c:   avail_min    : 7759
E: [alsa-sink] alsa-util.c:   period_event : 0
E: [alsa-sink] alsa-util.c:   start_threshold  : -1
E: [alsa-sink] alsa-util.c:   stop_threshold   : 1132462080
E: [alsa-sink] alsa-util.c:   silence_threshold: 0
E: [alsa-sink] alsa-util.c:   silence_size : 0
E: [alsa-sink] alsa-util.c:   boundary     : 1132462080
E: [alsa-sink] alsa-util.c:   appl_ptr     : 396378
E: [alsa-sink] alsa-util.c:   hw_ptr       : 491280






> I have tried on AT91 linux as well as on kernel 3.10.10-rt7 with no
> success.
>
> Please advice,
> Akshay
>
>

Re: Fwd: Overrun Errors - SAM9G

[Bo Shen]

Hi Akshay,

On 07/17/2014 08:54 PM, Akshay Mishra wrote:
> Hello,
>      I am trying a simple alsa capture on the Atmel ARM9 (SAM9G45). While
> only capture runs fine, putting any os call on the same thread gives XRUNs.
>
> Even a innocent usleep(1) seems to lead to regular XRUNs. Eventually I want
> to dump this capture on the serial port and I am not able to get past this.

Do you test with alsa utils. If yes, where you add the usleep(1) in code?

> I have tried on AT91 linux as well as on kernel 3.10.10-rt7 with no success.

I try both kernel and don't reproduce this issue with alsa utils.

> Please advice,
> Akshay

Best Regards,
Bo Shen

Re: Fwd: Overrun Errors - SAM9G

[Akshay Mishra]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

On 22 July 2014 07:57, Bo Shen <voice.shen@atmel.com> wrote:

> Hi Akshay,
>
>
> On 07/17/2014 08:54 PM, Akshay Mishra wrote:
>
>> Hello,
>>      I am trying a simple alsa capture on the Atmel ARM9 (SAM9G45). While
>> only capture runs fine, putting any os call on the same thread gives
>> XRUNs.
>>
>> Even a innocent usleep(1) seems to lead to regular XRUNs. Eventually I
>> want
>> to dump this capture on the serial port and I am not able to get past
>> this.
>>
>
> Do you test with alsa utils. If yes, where you add the usleep(1) in code?
>
>
>  I have tried on AT91 linux as well as on kernel 3.10.10-rt7 with no
>> success.
>>
>
> I try both kernel and don't reproduce this issue with alsa utils.
>
>
Bo, I put usleep(x) after the snd_pcm_readi. I also tried with this code
(attached).
usleep at Line 88 gives the error.

Another observation is, disabling HRTimer the -EPIPE error was not seen but
I need further tests to be sure about this behaviour.

The code is from here (http://www.linuxjournal.com/node/6735/print).




>  Please advice,
>> Akshay
>>
>
> Best Regards,
> Bo Shen
>
>

[-- Attachment #2: cap.c --]
[-- Type: text/x-csrc, Size: 2899 bytes --]

/*

This example reads from the default PCM device
and writes to standard output for 5 seconds of data.

*/

/* Use the newer ALSA API */
#define ALSA_PCM_NEW_HW_PARAMS_API

#include <alsa/asoundlib.h>
#include <time.h>

int main() {
  long loops;
  int rc;
  int size;
  snd_pcm_t *handle;
  snd_pcm_hw_params_t *params;
  unsigned int val;
  int dir;
  snd_pcm_uframes_t frames;
  char *buffer;

  /* Open PCM device for recording (capture). */
  rc = snd_pcm_open(&handle, "default",
                    SND_PCM_STREAM_CAPTURE, 0);
  if (rc < 0) {
    fprintf(stderr,
            "unable to open pcm device: %s\n",
            snd_strerror(rc));
    exit(1);
  }

  /* Allocate a hardware parameters object. */
  snd_pcm_hw_params_alloca(&params);

  /* Fill it in with default values. */
  snd_pcm_hw_params_any(handle, params);

  /* Set the desired hardware parameters. */

  /* Interleaved mode */
  snd_pcm_hw_params_set_access(handle, params,
                      SND_PCM_ACCESS_RW_INTERLEAVED);

  /* Signed 16-bit little-endian format */
  snd_pcm_hw_params_set_format(handle, params,
                              SND_PCM_FORMAT_S16_LE);

  /* Two channels (stereo) */
  snd_pcm_hw_params_set_channels(handle, params, 2);

  /* 44100 bits/second sampling rate (CD quality) */
  val = 48000;
  snd_pcm_hw_params_set_rate_near(handle, params,
                                  &val, &dir);

  /* Set period size to 32 frames. */
  frames = 32;
  snd_pcm_hw_params_set_period_size_near(handle,
                              params, &frames, &dir);
	printf("Frames %d\n",frames);


  /* Write the parameters to the driver */
  rc = snd_pcm_hw_params(handle, params);
  if (rc < 0) {
    fprintf(stderr,
            "unable to set hw parameters: %s\n",
            snd_strerror(rc));
    exit(1);
  }

  /* Use a buffer large enough to hold one period */
  snd_pcm_hw_params_get_period_size(params,
                                      &frames, &dir);
  size = frames * 4; /* 2 bytes/sample, 2 channels */
  buffer = (char *) malloc(size);

  snd_pcm_hw_params_get_period_time(params,
                                         &val, &dir);
  loops = 5000000 / val;

  while (1) {
    loops--;
    rc = snd_pcm_readi(handle, buffer, frames);
	usleep(1); //--Akshay -- This fails with my config
    if (rc == -EPIPE) {
      /* EPIPE means overrun */
      fprintf(stderr, "overrun occurred %lu\n",(unsigned)time(NULL));
      snd_pcm_prepare(handle);
    } else if (rc < 0) {
      fprintf(stderr,
              "error from read: %s\n",
              snd_strerror(rc));
    } else if (rc != (int)frames) {
      fprintf(stderr, "short read, read %d frames\n", rc);
    }
   // rc = write(1, buffer, size);
//    if (rc != size)
 //     fprintf(stderr,
  //            "short write: wrote %d bytes\n", rc);
  }

  snd_pcm_drain(handle);
  snd_pcm_close(handle);
  free(buffer);

  return 0;
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Fwd: Overrun Errors - SAM9G

[Bo Shen]

Hi Akshay,

On 07/22/2014 10:38 AM, Akshay Mishra wrote:
> On 22 July 2014 07:57, Bo Shen <voice.shen@atmel.com
> <mailto:voice.shen@atmel.com>> wrote:
>
>     Hi Akshay,
>
>
>     On 07/17/2014 08:54 PM, Akshay Mishra wrote:
>
>         Hello,
>               I am trying a simple alsa capture on the Atmel ARM9
>         (SAM9G45). While
>         only capture runs fine, putting any os call on the same thread
>         gives XRUNs.
>
>         Even a innocent usleep(1) seems to lead to regular XRUNs.
>         Eventually I want
>         to dump this capture on the serial port and I am not able to get
>         past this.
>
>
>     Do you test with alsa utils. If yes, where you add the usleep(1) in
>     code?
>
>
>         I have tried on AT91 linux as well as on kernel 3.10.10-rt7 with
>         no success.
>
>
>     I try both kernel and don't reproduce this issue with alsa utils.
>
>
> Bo, I put usleep(x) after the snd_pcm_readi. I also tried with this code
> (attached).
> usleep at Line 88 gives the error.
>
> Another observation is, disabling HRTimer the -EPIPE error was not seen
> but I need further tests to be sure about this behaviour.

In contrast, I enable HRTimer, the -EPIPE error is gone.
I briefly go through the code: usleep --> .. --> nanosleep (define in 
<kernel/hrtime.c>)

Actually, I can not understand why you add a usleep(1) in this piece of 
code. :(

> The code is from here (http://www.linuxjournal.com/node/6735/print).
>
>
>         Please advice,
>         Akshay
>

Best Regards,
Bo Shen

Re: Fwd: Overrun Errors - SAM9G

[Akshay Mishra]

On 22 July 2014 11:32, Bo Shen <voice.shen@atmel.com> wrote:

> Hi Akshay,
>
>
> On 07/22/2014 10:38 AM, Akshay Mishra wrote:
>
>> On 22 July 2014 07:57, Bo Shen <voice.shen@atmel.com
>> <mailto:voice.shen@atmel.com>> wrote:
>>
>>     Hi Akshay,
>>
>>
>>     On 07/17/2014 08:54 PM, Akshay Mishra wrote:
>>
>>         Hello,
>>               I am trying a simple alsa capture on the Atmel ARM9
>>         (SAM9G45). While
>>         only capture runs fine, putting any os call on the same thread
>>         gives XRUNs.
>>
>>         Even a innocent usleep(1) seems to lead to regular XRUNs.
>>         Eventually I want
>>         to dump this capture on the serial port and I am not able to get
>>         past this.
>>
>>
>>     Do you test with alsa utils. If yes, where you add the usleep(1) in
>>     code?
>>
>>
>>         I have tried on AT91 linux as well as on kernel 3.10.10-rt7 with
>>         no success.
>>
>>
>>     I try both kernel and don't reproduce this issue with alsa utils.
>>
>>
>> Bo, I put usleep(x) after the snd_pcm_readi. I also tried with this code
>> (attached).
>> usleep at Line 88 gives the error.
>>
>> Another observation is, disabling HRTimer the -EPIPE error was not seen
>> but I need further tests to be sure about this behaviour.
>>
>
> In contrast, I enable HRTimer, the -EPIPE error is gone.
> I briefly go through the code: usleep --> .. --> nanosleep (define in
> <kernel/hrtime.c>)
>
>
do you mean, disabling HRTimer you had -EPIPE ? I am positive on disabling
the HRTimer, CPU Freeze which made the -EPIPE vanish and the moment I
enable it, I again get -EPIPE. :-(


> Actually, I can not understand why you add a usleep(1) in this piece of
> code. :(
>
>

Bo, as I mentioned earlier -- the usleep is only a placeholder. Any system
call (like write to serial port) also gives same result but since I cannot
ask you to do serial transmit - you may not have it setup I asked you to do
a usleep since it gives me the same result.

I have requested for a SAM9G45-EK from the local Atmel office and once I
get it I shall inform you further on this on the same platform.

-Akshay



>
>  The code is from here (http://www.linuxjournal.com/node/6735/print).
>>
>>
>>         Please advice,
>>         Akshay
>>
>>
> Best Regards,
> Bo Shen
>
>