disorder-playrtp now releases its lock around activate/deactivate

calls.  This necessary since deactivate may block if a sample
collection callback is still running (in this case it will be blocked
indefinitely).  It actually happens with the Core Audio backend but it
could apply to other APIs too.

diff --git a/clients/playrtp.c b/clients/playrtp.c
index 9647437..92cbb75 100644 (file)
--- a/clients/playrtp.c
+++ b/clients/playrtp.c
@@ -763,7 +763,9 @@ int main(int argc, char **argv) {
     info("Playing...");
     next_timestamp = pheap_first(&packets)->timestamp;
     active = 1;
+    pthread_mutex_unlock(&lock);
     backend->activate();
+    pthread_mutex_lock(&lock);
     /* Wait until the buffer empties out */
     while(nsamples >= minbuffer
          || (nsamples > 0
@@ -771,7 +773,9 @@ int main(int argc, char **argv) {
       pthread_cond_wait(&cond, &lock);
     }
     /* Stop playing for a bit until the buffer re-fills */
+    pthread_mutex_unlock(&lock);
     backend->deactivate();
+    pthread_mutex_lock(&lock);
     active = 0;
     /* Go back round */
   }

diff --git a/lib/uaudio.h b/lib/uaudio.h
index aa686d0..e796393 100644 (file)
--- a/lib/uaudio.h
+++ b/lib/uaudio.h
@@ -34,6 +34,15 @@ extern size_t uaudio_sample_size;
  * @param max_samples How many samples to supply
  * @param userdata As passed to uaudio_open()
  * @return Number of samples filled
+ *
+ * This function should not block if possible (better to fill the buffer with
+ * 0s) and should definitely not block indefinitely.  This great caution with
+ * any locks or syscalls!  In particular avoid it taking a lock that may be
+ * held while any of the @ref uaudio members are called.
+ *
+ * If it's more convenient, it's OK to return less than the maximum number of
+ * samples (including 0) provided you expect to be called again for more
+ * samples immediately.
  */
 typedef size_t uaudio_callback(void *buffer,
                                size_t max_samples,