Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Gabriel M. Beddingfield" <gabrbedd@gmail.com>
To: Adarsh <punia.adarsh@gmail.com>, alsa-devel@alsa-project.org
Subject: Re: Need Help: Repeated Jackhammer noise after several hours of play and heavy cpu usage in snd_pcm_dmix_sync_area
Date: Wed, 19 Feb 2014 07:16:51 -0800	[thread overview]
Message-ID: <5304CAE3.1000303@gmail.com> (raw)
In-Reply-To: <CANxfbX_o=UcTz0Sjno=zkEns4MGdrjnsbJmP0J=7O8owu7_8+g@mail.gmail.com>

Hi Adarsh,

On 02/19/2014 04:07 AM, Adarsh wrote:
> Hi,
>
> We are facing a issue where if gdb is attached to the our long running
> sound process and continued,
> jackhammer sound is played over and over again abusing the speakers.
>
> Process details:
> 1. We are using RW_INTERLEAVED access as described in write_loop method in
> /test/pcm.c and opening 'default' device.
> 2. However to disable the underruns, the
> snd_pcm_sw_params_set_stop_threshold is set to 0x7fffffff which is greater
> than boundary
> value.

This doesn't prevent underruns. Underruns happen when the software 
doesn't keep up with the hardware.

What this disables is your ability to detect and recover from an 
underrun. So, what you're experiencing is expected behavior.  If you 
never reach the stop threshold but userspace fails to write new audio to 
the buffer.  Since you instructed the driver/hardware to *not* stop in 
the event of an underrun, it repeatedly cycles on the same, stale 
buffer. This gives you the "jackhammer" sound.

> 3.Period size is 1024 and buffer size is 2048. We try to write period_size
> no of frames using snd_pcm_writei.
> (I am attaching a sample program which shows this behaviour.)
>
> Steps to Reproduce:
> 1. Left process running for over 12 hours.
> 2. gdb is attached to the process and continued inside gdb.

When gdb attached to the process, you certainly stopped writing new 
audio to the buffer because your process got a SIGSTOP... causing all 
threads to freeze.

> 3. At this point, the thread went into a tight loop taking >100% cpu and
> repeatedly playing same sound. It did not recover for a long time.

...I'm not sure what you're seeing here.  Possibly dmix is trying to 
make the best of a bad situation.

> Is it that setting of stop threshold to 0x7fffffff is triggering this and
> attaching gdb is making the buffer pointers misbehave?
> If so, what can be done if we do not want PCM to stop? I have tried by
> setting silence threshold and silence size to let alsa
> play silence by itself but still observed the issue.

It depends on what you're trying to solve by attaching with gdb.

GDB is good for a lot of things, but solving problems in real-time 
systems (like audio) has never been one of them. So, chances are that 
gdb is the wrong tool for what you're trying to do.

-gabe

  reply	other threads:[~2014-02-19 15:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-19 12:07 Need Help: Repeated Jackhammer noise after several hours of play and heavy cpu usage in snd_pcm_dmix_sync_area Adarsh
2014-02-19 15:16 ` Gabriel M. Beddingfield [this message]
2014-02-20  9:57 ` Clemens Ladisch
2014-02-20 11:07   ` Adarsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5304CAE3.1000303@gmail.com \
    --to=gabrbedd@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=punia.adarsh@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox