[alsa-devel] Infinite loop in snd_pcm_hw_htimestamp() for capture PCMs?
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
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
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
participants (2)
-
Andrew Eikum -
Takashi Iwai