Infinite loop in snd_pcm_hw_htimestamp() for capture PCMs?

Infinite loop in snd_pcm_hw_htimestamp() for capture PCMs?

[Andrew Eikum]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Hi folks,

I've found some unexpected behavior in alsa-lib. The attached program
uses 100% CPU in an infinite loop, when I'd expect it to return either
an error or a valid htimestamp. I believe the loop occurs in
<src/pcm/pcm_hw.c:snd_pcm_hw_htimestamp()>. Am I not supposed to call
htimestamp() on this type of PCM? Is the PCM still in an invalid state
when htimestamp() is called?

Card: HDA ATI SB
Chip: Realtek ALC889

Happy for any insight.
Andrew

[-- Attachment #2: capture_inf_loop.c --]
[-- Type: text/x-csrc, Size: 2094 bytes --]

/* Causes an infinite loop in alsa-lib's snd_pcm_hw_htimestamp() in the
 * capture direction
 *
 * Build with:
 * $ gcc -o test -Wall capture_inf_loop.c -lasound
 */

#include <alsa/asoundlib.h>

int main(int argc, char **argv)
{
    snd_pcm_t *pcm;
    snd_pcm_uframes_t avail;
    snd_pcm_hw_params_t *hw_params;
    int err;
    struct timespec ts;
    unsigned int rate = 44100;

    err = snd_pcm_open(&pcm, "default", SND_PCM_STREAM_CAPTURE,
            SND_PCM_NONBLOCK);
    if(err < 0){
        fprintf(stderr, "snd_pcm_open: %s\n", snd_strerror(err));
        return 1;
    }

    snd_pcm_hw_params_malloc(&hw_params);

    err = snd_pcm_hw_params_any(pcm, hw_params);
    if(err < 0){
        fprintf(stderr, "snd_pcm_hw_params_any: %s\n", snd_strerror(err));
        return 1;
    }

    err = snd_pcm_hw_params_set_access(pcm, hw_params,
            SND_PCM_ACCESS_RW_INTERLEAVED);
    if(err < 0){
        fprintf(stderr, "snd_pcm_hw_params_set_access: %s\n",
                snd_strerror(err));
        return 1;
    }

    err = snd_pcm_hw_params_set_format(pcm, hw_params,
            SND_PCM_FORMAT_S16_LE);
    if(err < 0){
        fprintf(stderr, "snd_pcm_hw_params_set_access: %s\n",
                snd_strerror(err));
        return 1;
    }

    err = snd_pcm_hw_params_set_rate_near(pcm, hw_params, &rate, NULL);
    if(err < 0){
        fprintf(stderr, "snd_pcm_hw_params_set_rate_near: %s\n",
                snd_strerror(err));
        return 1;
    }

    err = snd_pcm_hw_params_set_channels(pcm, hw_params, 2);
    if(err < 0){
        fprintf(stderr, "snd_pcm_hw_params_set_rate_near: %s\n",
                snd_strerror(err));
        return 1;
    }

    err = snd_pcm_hw_params(pcm, hw_params);
    if(err < 0){
        fprintf(stderr, "snd_pcm_hw_params: %s\n", snd_strerror(err));
        return 1;
    }

    fprintf(stderr, "avail_update\n");
    snd_pcm_avail_update(pcm);

    fprintf(stderr, "entering htimestamp...\n");
    snd_pcm_htimestamp(pcm, &avail, &ts);
    fprintf(stderr, "done with htimestamp\n");

    snd_pcm_close(pcm);

    return 0;
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Infinite loop in snd_pcm_hw_htimestamp() for capture PCMs?

[Takashi Iwai]

At Fri, 21 Sep 2012 10:53:43 -0500,
Andrew Eikum wrote:
> 
> Hi folks,
> 
> I've found some unexpected behavior in alsa-lib. The attached program
> uses 100% CPU in an infinite loop, when I'd expect it to return either
> an error or a valid htimestamp. I believe the loop occurs in
> <src/pcm/pcm_hw.c:snd_pcm_hw_htimestamp()>. Am I not supposed to call
> htimestamp() on this type of PCM? Is the PCM still in an invalid state
> when htimestamp() is called?

Indeed, it's a bug in dmix/dsnoop/dshare plugins.
Fixed now in git tree.


thanks,

Takashi

Re: Infinite loop in snd_pcm_hw_htimestamp() for capture PCMs?

[Andrew Eikum]

On Fri, Sep 21, 2012 at 06:02:07PM +0200, Takashi Iwai wrote:
> At Fri, 21 Sep 2012 10:53:43 -0500,
> Andrew Eikum wrote:
> > I've found some unexpected behavior in alsa-lib. The attached program
> > uses 100% CPU in an infinite loop, when I'd expect it to return either
> > an error or a valid htimestamp. I believe the loop occurs in
> > <src/pcm/pcm_hw.c:snd_pcm_hw_htimestamp()>. Am I not supposed to call
> > htimestamp() on this type of PCM? Is the PCM still in an invalid state
> > when htimestamp() is called?
> 
> Indeed, it's a bug in dmix/dsnoop/dshare plugins.
> Fixed now in git tree.
> 

Thanks for the fix.

Andrew