Skip to content
This repository has been archived by the owner on Jan 16, 2024. It is now read-only.

Alexa stops responding a few minutes after startup #532

Closed
ofuangka opened this issue Feb 24, 2018 · 10 comments
Closed

Alexa stops responding a few minutes after startup #532

ofuangka opened this issue Feb 24, 2018 · 10 comments

Comments

@ofuangka
Copy link

ofuangka commented Feb 24, 2018

After a couple of minutes, Alexa stops responding. It works for the first couple of minutes, and I'm able to ask questions and receive responses, but then it stops. This happens regardless of whether I ask any questions.

At first, at failure time, I was receiving the following log:

src/hostapi/alsa/pa_linux_alsa.c :3636 :
PaAlsaStreamComponent_BeginPolling: assertion « ret == self->nfds » failed.

I then recompiled portaudio/avs-device-sdk with NDEBUG to turn assertions off, now I'm getting this:

2018-02-24 15:48:28.689 [ 15] I AbstractKeywordDetector:readFromStreamFailed:reason=readerTimeOut
2018-02-24 15:48:29.690 [ 15] I AbstractKeywordDetector:readFromStreamFailed:reason=readerTimeOut
2018-02-24 15:48:30.690 [ 15] I AbstractKeywordDetector:readFromStreamFailed:reason=readerTimeOut

This message repeats until I kill the process, restart, and it all happens again.

My microphone is shared via dsnoop. I tried ending the other process that is listening, but the issue still occurs:

/etc/asound.conf
pcm.!default {
  type            asym
  playback.pcm    "hw:0"
  capture.pcm {
    type          plug
    slave.pcm     "dsnoop:2,0,0,S16_LE,16000"
  }
}

What version of the AVS Device SDK are you using?

1.5.0

Tell us what hardware you're using:

Raspberry Pi 3
Playstation Eye for microphone

Tell us about your OS (Type & version):

ArchLinux Arm

Edit: Changing from dsnoop to hw seems to resolve the issue, but I would like to continue using dsnoop. I don't believe this was an issue with alexa-avs-sample-app.

@mavamazon
Copy link
Contributor

Hi @ofuangka!

It seems that even having dsnoop does not allow two applications to record simultaneously. Does the simultaneous recording work with other apps?

In general, SDK uses the default recording device. The comments you provided show that the problem is either in PortAudio or in the OS audio configuration. Anyway, can you answer several questions to understand the problem better:

  • Is another device actually recording at the moment SDK stops. Is the other device able to record after SDK stops?
  • Is it always reproducible?

@ofuangka
Copy link
Author

ofuangka commented Feb 27, 2018

@mavamazon

Is another device actually recording at the moment SDK stops. Is the other device able to record after SDK stops?

By device, do you mean application? If so, then yes the other application is recording both before and after the SDK stops. However, I had tried stopping the other application before starting the Alexa sample app, and the same result occurred as described above.

Is it always reproducible?

Yes.

When I get some time this weekend I'll try the compiling against the nightly PortAudio to see if that fixes it. If that doesn't work I'll probably go back to the Java alexa-avs-sample-app, which as stated before, seemed to be working with dsnoop.

Edit: No luck after compiling with PortAudio HEAD

@kencecka
Copy link
Contributor

Hi @ofuangka,

I'm finding a handful of references to the same assertion you are seeing in various audio application forums, but no one seems to have chased it to root cause yet. I did finally find a bug report filed directly against pulseaudio here.

Of particular interest in the bug report: "this happens only with Alsa 1.1.4.1 (and 1.1.4), but does not happen with the older 1.1.3". If you have any ability to roll back to an older ALSA release, it may work around the problem until the PulseAudio team gets to the bottom of it.

Ken

@ofuangka
Copy link
Author

@kencecka

Thanks for finding that. I'd rather not roll back my ALSA, but will consider it if all else fails.

@kencecka
Copy link
Contributor

I understand. This sounds like a bug in ALSA or PulseAudio, and presumably they'll get to the bottom of it in a future release, but that may take some time. You might want to chime in on the pulseaudio bug report to see if you can get them more interested in fixing it.

Let us know if there's anything else we can help with.

Ken

@sanjayrd sanjayrd closed this as completed Mar 5, 2018
@subjectxbj
Copy link

I also met this problem when I change the capture device from "hw" to "dsnoop".
@ofuangka How did you fix this problem if keep using "dsnoop"? Thanks.

@AnupB-REPL
Copy link

I also get same problem:
2019-09-14 06:38:41.431 [ 3] I AbstractKeywordDetector:readFromStreamFailed:reason=readerTimeOut

@dubaleeiro
Copy link

Same problem here using Raspberry Pi Zero W, Linux raspberrypi 4.19.75, Raspbian Buster Lite. Would be great if someone could give some hints on how to solve it...

@hongbosen
Copy link

me too ,I using Raspberry Pi Zero WH,I don't known how to solve it....

@shivasiddharth
Copy link

Install pulseaudio

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants