[alsa-devel] SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

[Trent Reed]

On Tue, Jul 5, 2016 at 1:46 AM, Trent Reed <treed0803 at gmail.com> wrote:

> On Tue, Jul 5, 2016 at 12:38 AM, Takashi Iwai <tiwai at suse.de> wrote:
>
>> Please don't drop Cc to ML.  Also avoid top-post.
>>
>
> Whoops! Sorry - not too familiar with the etiquette yet. (Dropped Cc was
> an honest mistake, reply instead of reply-all).
>
>
>> 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
>>
>
> It doesn't happen always, but it usually happens more often than not -
> sometimes I'll go a few attempts without hearing the issue, and other times
> it'll be consistent. The only constant seems to be that I have never heard
> it occur when I am running snd_pcm_wait() (e.g. without --test-nowait). I
> will keep trying this though to see if that ever changes.
>
> Here are my attempted recordings:
>
> Non-Blocking, No-Wait (produces static):
> `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=256 --nonblock
> --test-nowait -d5 > s16le-c2-p256-nonblock-nowait.wav`
> https://drive.google.com/open?id=0B-1aumGKQcQTR0ZtUFlaV1Q5cFU
>
> Non-Blocking, Wait (does not produce static):
> `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=256 --nonblock -d5 >
> s16le-c2-p256-nonblock-wait.wav`
> https://drive.google.com/open?id=0B-1aumGKQcQTa2pGUWpTWmc1QW8
>
> At first, I thought it had to do with the period - but here I attempt to
> use the default period for arecord (unsure of what the default gets set to).
> `arecord -Dhw:2 -fS16_LE -r48000 -c2 --nonblock --test-nowait -d5 >
> s16le-c2-nonblock-nowait.wav`
> https://drive.google.com/open?id=0B-1aumGKQcQTa280VG9LbHlreU0
>
> To be absolutely sure that period size didn't play a role, I asked for a
> specific size:
> `arecord -Dhw:2 -fS16_LE -r48000 -c2 --period-size=1024 --nonblock
> --test-nowait -d5 > s16le-c2-p1024-nonblock-nowait.wav`
> https://drive.google.com/open?id=0B-1aumGKQcQTZlRCQ0lvek9YN3M
>
> And it doesn't appear to relate to the sample rate:
> `arecord -Dhw:2 -fS16_LE -r44100 -c2 --nonblock --test-nowait -d5 >
> s16le-44100-c2-nonblock-nowait.wav`
> https://drive.google.com/open?id=0B-1aumGKQcQTZFNmTGt5VXJKQTg
>
> I also can get it to reproduce using --mmap flag:
> `arecord -Dhw:2 -fS16_LE -r48000 -c2 --nonblock --test-nowait --mmap -d5 >
> s16le-c2-mmap-nonblock-nowait.wav`
> https://drive.google.com/open?id=0B-1aumGKQcQTWDZ6cFlSZjA5ek0
>
> Let me know how I can help further debug. :)
>
> Thanks,
> - Trent Reed
>
>
>> >
>> > 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/985c5d5c3d295245e19006a27be447
>> c3
>> > > > >
>> > > > > 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
>> > > >
>>
>
Hey Takashi,

Just wondering if there is any update on this or if you need any more
information? Were you able to repro this? Any way I can help?

Thanks,
- Trent Reed