Re: SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

[Takashi Iwai <tiwai@suse.de>]

On Sat, 02 Jul 2016 23:58:28 +0200,
Trent Reed wrote:
> 
> (Ping)
> 
> I'm afraid I still don't understand why this is failing. I found that a
> call to sdn_pcm_wait() when -EAGAIN is returned fixes the problem because
> it waits for samples to be ready, but I don't understand why it is a
> problem in the first place. Much of the sample code is written in a way
> that suggests that the call to snd_pcm_wait() is optional, and only
> required when directly reading/writing from the device (MMAP, I'm not doing
> this).
> 
> I'm just wondering what is wrong with basically looping over a call to
> snd_pcm_readi() in non-blocking mode, reacting to errors, and capturing
> frames. This produces awful static (which is basically garbage samples), is
> it a requirement that I call snd_pcm_wait() when -EAGAIN is passed back to
> wait for a full period to be ready?

Well, in the API level, it should work as you expected.  So there must
be definitely some bug(s).  But it's hard to spot out, as there are
several layers behind the scene.

As a first shot, try to reproduce without alsa-lib plugins, i.e. only
with "hw" PCM device, if not done yet.  Also, it's interesting to see
whether it happens with or without mmap r/w.

Another point is whether it depends on the parameter.  Did you try
48kHz instead of 44.1kHz?


Takashi


> 
> Thanks,
> - Trent Reed
> 
> 
> On Tue, Jun 28, 2016 at 7:27 PM, Trent Reed <treed0803@gmail.com> wrote:
> 
> > Hey All,
> >
> > I've been banging my head against the wall for about a week on this bug.
> > The following gist shows my sample reproduction code:
> > https://gist.github.com/TReed0803/985c5d5c3d295245e19006a27be447c3
> >
> > I'm simply opening up a non-blocking PCM capture stream and writing the
> > contents of the reads to stdout.
> > (Originally, I was writing to the playback stream, but I was hearing this
> > strange static occasionally!)
> >
> > It's the static I'm trying to debug. It doesn't happen every time. In
> > fact, sometimes I'll go a few consecutive executions without hearing it.
> > I was able to capture some of the bad data, and I loaded it up in Audacity
> > for visualization:
> >
> > https://drive.google.com/file/d/0B-1aumGKQcQTcUJoZzIwRWhYSFE/view?usp=sharing
> >
> > It looks like the internal buffer occasionally is sending me more data
> > than it actually captured, and I end up either reading old PCM data from
> > the internal ring buffer, or (at the very beginning) a bunch of zeros.
> >
> > Can anyone help me understand what is going on? What could cause these
> > definitely incorrect samples to be recorded? (I get the same effect
> > regardless of hardware, but I will list hardware just in case.)
> >
> > I hope I have all the information you might need:
> > Hardware: Samson Meteor Mic (USB-Audio, USB Mixer) [Though, it even
> > happens with my built-in microphone]
> > ALSA version: Advanced Linux Sound Architecture Driver Version
> > k4.4.0-28-generic.
> > apt-cache policy (installed alsa-lib version): 1.1.0-0ubuntu1
> >
> > Thanks,
> > - Trent Reed
> >
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>