Here are the results: 1. `arecord` while pa is *not* suspended and while the mic is working fine returns "device is busy"
``` % arecord -vv -fdat -c 2 -D hw:0,0 test.wav arecord: main:722: audio open error: Device or resource busy ``` 2. if the mic is working just before issuing the command `pasuspender -- arecord -vv -fdat -c 2 -D hw:0,0 test.wav` then `arecord` works and the sound from the mic is recorded 3. if the mic is *not* working just before issuing the command `pasuspender -- arecord -vv -fdat -c 2 -D hw:0,0 test.wav` then `arecord` does not record any noise 4. if the mic is working just before issuing the command `pasuspender -- yes > /dev/null` and I suspend and resume without killing the process then the mic is *not* working after the resume, nor after I kill the process after resuming On 18 April 2014 16:39, Felipe Sateler <fsate...@debian.org> wrote: > On Fri, Apr 18, 2014 at 1:31 PM, Stefan Krastanov > <krastanov.ste...@gmail.com> wrote: >> Hi, >> >> Here is the new log file: >> >> - starting pulse audio (not working) >> - tapping on the internal mic (not working) >> - tapping *very* hard on the internal mic (starts working) >> - suspend and resume (stops working) >> - starting gnome-sound-recorder (not working) >> - jiggling the volume bar in the control panel (starts working) > > This is starting to look like a kernel bug. Apparently the device is > put into suspended mode and for some reason it cannot bring it back: > >> ( 22.139| 16.978) I: [alsa-source-CS4206 Analog] alsa-source.c: Scheduling >> delay of 3955.27 ms > 10.00 ms, you might want >> ( 22.139| 0.000) D: [alsa-source-CS4206 Analog] alsa-util.c: Got POLLERR >> from ALSA >> ( 22.139| 0.000) D: [alsa-source-CS4206 Analog] alsa-util.c: Got POLLIN >> from ALSA >> ( 22.139| 0.000) D: [alsa-source-CS4206 Analog] alsa-util.c: PCM state is >> SUSPENDED >> ( 22.139| 0.000) I: [alsa-source-CS4206 Analog] (alsa-lib)pcm_hw.c: >> SNDRV_PCM_IOCTL_RESUME failed (-38) >> ( 22.144| 0.004) I: [alsa-source-CS4206 Analog] alsa-source.c: Starting >> capture. > > Lets try again but now bypassing pulseaudio: > > pasuspender -- arecord -vv -fdat -c 2 -D hw:0,0 test.wav > > I had to specify the -c 2 argument for the number of channels, but you > might not need to. > > Try this after the mic died with pulseaudio, as the dying might be > caused by pulseaudio sending the device to sleep. > > also maybe you could try doing: > > pasuspender -- yes > /dev/null > > This will suspend pulseaudio until you interrupt that process. Then > suspend the computer, bring it back and then try to record using > arecord. These two tests should tell us if the problem is in ALSA > rather than in pa. > >> >> If it might help, I cat repeat this with a stopwatch for easier >> reading of the log file? > > I didn't think of that! I'm going to ask that next time :) > >> >> Thanks for looking into this. > > No worries > > > -- > > Saludos, > Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
