[alsa-devel] Fwd: Overrun Errors - SAM9G
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
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
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
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
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
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, AkshayBest Regards, Bo Shen
participants (2)
-
Akshay Mishra -
Bo Shen