Hello Takashi,
On Wed, Jun 29, 2016 at 03:39:37PM +0200, Takashi Iwai wrote:
Do you think the problem is likely to come from an incorrect API usage from the application? Knowing this would significantly narrow down the search, because the problem could also come from within alsa itself.
The callling code from the application is quite complex, see here:
https://github.com/savoirfairelinux/ring-daemon/blob/master/src/media/audio/...
In particular, the assertion is triggered by the call to snd_pcm_avail_update() at line 694 (see the stack trace below).
I have too little time to investigate on this issue, but judging from the fact that there has been no such a report until now, I guess it's specific to your code. But I can't say sure, of course.
Well, I did find other projects having this issue:
https://aur.archlinux.org/packages/zoom/#comment-544696 http://ubuntuforums.org/showthread.php?t=2248373 https://github.com/js-platform/node-webrtc/issues/110 https://fedorahosted.org/fldigi/ticket/70
Although in most of these cases, the issue seems 100% reproducible (e.g. crash at startup). In our case, the assertion failure only happens when there is significant CPU load.
Is the relevant code path accessed concurrently? The possible race is the first suspect I'd always think of in such a case.
Good idea, I will check. Given it happens when the CPU is loaded, my guess is that "something" is done too late, which means that it works on "invalidated" data (this is all very vague, sorry).
Would you know a simple program using alsa-lib for sound capture, with which I could try to reproduce?
Baptiste