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).
Samuel
--- ./src/pcm/pcm.c.orig 2016-08-10 19:39:59.881564371 +0200
+++ ./src/pcm/pcm.c 2016-08-10 19:40:04.211539997 +0200
@@ -2544,6 +2544,7 @@
pcm->fast_op_arg = pcm;
INIT_LIST_HEAD(&pcm->async_handlers);
#ifdef THREAD_SAFE_API
+ pcm->thread_safe = 1;
pthread_mutex_init(&pcm->lock, NULL);
{
static int default_thread_safe = -1;
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
