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=c4b690278eeaf9a6805f67f6709e4aa33e58773a;hp=7a8a1d155267fb6e21ddaa0787d121ec47a15bf2 I don't know exactly the others. Anyway, I'll continue to investigate these issues and cooperate to solve them. Thanks Takashi Sakamoto
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel