On Thu, 15 Mar 2018 16:07:31 +0100, Wischer, Timo (ADITG/ESB) wrote: > > > We need to check it, of course. But the behavior of the prepare > > function is certainly different from others, so it's more likely a > > bug. > > I could provide a fix for the IO plug API for prepare and draining. Yes, these are very trivial changes. > > This should be notified to ioplug via snd_pcm_ioplug_set_state(). > > Without an additional variable snd_pcm_ioplug_set_state() has to be called from the JACK thread. > But snd_pcm_ioplug_set_state() is not thread safe. Well, but your internal state copy is also not thread safe as of this patch, after all. > > That'd be great if everything is ready, but this can't be a reason to > > add a shadow state and modify the code as in the patch for now. > > At the end I would like to use functions similar to READ_ONCE() and WRITE_ONCE() to access the state (known from the Linux kernel [1]). > But I think this should not be part of the ALSA library because it is for most IO plugins not required. > Therefore I need to have an internal copy of the state which will only be accessed with READ_ONCE() and WRITE_ONCE(). > > You are right, it is not yet required but at the end I have to implement it. > > Do you think we should implement such a synchronization into the ALSA lib? > > [1] https://www.kernel.org/doc/Documentation/memory-barriers.txt I really would like to avoid that, at least, not introducing any dependency into alsa-lib. The usage inside a plugin is another question, and it would depend on the implementation details. A dependency in plugin may cause a messy conflict when different versions are used in a same application. So, in general, it'd be best for a plugin to be self-contained. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
