SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

[Trent Reed]

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

Re: SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

[Trent Reed]

(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?

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
>

Re: SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

[Takashi Iwai]

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
> 

Re: 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@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@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
> > >

Re: SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

[Trent Reed]

On Tue, Jul 5, 2016 at 12:38 AM, Takashi Iwai <tiwai@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@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@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
> > > >
>

Re: 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@gmail.com> wrote:

> On Tue, Jul 5, 2016 at 12:38 AM, Takashi Iwai <tiwai@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@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@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@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

Re: SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts

[Takashi Iwai]

On Sat, 06 Aug 2016 21:13:54 +0200,
Trent Reed wrote:
> 
> On Tue, Jul 5, 2016 at 1:46 AM, Trent Reed <treed0803@gmail.com> wrote:
> 
> > On Tue, Jul 5, 2016 at 12:38 AM, Takashi Iwai <tiwai@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@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@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@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?

Sorry, I really have no time to check this issue right now.
Hopefully someone else tackles it...


Takashi