[alsa-devel] SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

[Takashi Iwai]

Please don't drop Cc to ML.  Also avoid top-post.

On Tue, 05 Jul 2016 09:02:12 +0200,
Trent Reed wrote:
> 
> Thanks Takashi,
> 
> My implementation does only use the "hw:N" devices, unfortunately - I am
> not using MMAP because I was under the impression that you must poll when
> directly accessing the hardware. And yes, 48kHz is the exact rate I'm
> attempting. :(
> I do have an update, though - I'm able to reproduce the issue quite simply
> by running the ALSA test application latency with the following command:
> 
> `latency -P <playback-device> -C <capture-device> -r 48000`
> 
> This, as far as I understand from the source code, should open R/W
> interleaved streams on ("hw:2" is what I'm using for both, though the
> problem persists in non-duplex mode, e.g. "hw:2" "hw:0") in non-blocking
> mode without polling.
> 
> What happens is the latency application does normalize around some value
> (say, 16ms roundtrip time), but the audio is awful and broken, a lot of
> this "static" I'm talking about. It seems to me that it's the same problem
> that I have in my above-mentioned sample code.
> 
> I would love to help more, so if I can in any way, please let me know! But
> I feel at a loss for how to further debug.

The latency program is too complex to analyze the issue.  Check
arecord with --nonblock --test-nowait options and with the hw device.
Does the issue happen always?  Or does it depend on the buffer or
period size?


Takashi
> 
> Thanks,
> - Trent Reed
> 
> On Mon, Jul 4, 2016 at 11:52 PM, Takashi Iwai <tiwai at suse.de> wrote:
> 
> > 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 at 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 at alsa-project.org
> > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > >