Hi,
On Aug 17 2016 06:03, Samuel Thibault wrote:
Hello,
We are having odd issues with libasound 1.1.2 which we didn't have with libasound 1.1.1, more precisely
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833950
so I'm having a look at the locking API introduced in 1.1.2, and there are some oddities:
snd_pcm_new seems to initialize pcm->thread_safe to 0 by default, this does not seem safe. The attached patch initializes it to 1, which fixes the bug in our tests.
snd_pcm_hw_open_fd forces it to 1, thus ignoring what snd_pcm_new set.
one can find both __snd_pcm_lock and snd_pcm_lock functions, what is the expected difference between them?
__snd_pcm_lock takes locks when thread_safe >= 0, while snd_pcm_lock takes locks when thread_safe == 0, this looks really odd.
libasound could just not link against libpthread, pthread_mutex_lock/unlock are already provided as empty stubs by libc, the overhead will thus only be hit when the application links against libpthread (libasound will then properly use pthread locks).
Thanks for this information. Unfortunately, committer of this modification (a subsystem maintainer) has a summer vacation, so it's delayed for you to get replies for to questions.
In my opinion, the second item you addressed to is a bug of this commit, to introduce the environment variable.
pcm: Add LIBASOUND_THREAD_SAFE env variable check http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=c4b690278eeaf9a68...
I don't know exactly the others. Anyway, I'll continue to investigate these issues and cooperate to solve them.
Thanks
Takashi Sakamoto