Re: jack-driver & jack_ringbuffer

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Fri, Jun 30, 2017 at 10:35:29PM +0200, Tim Janik wrote:
> please go ahead and use teh jack ringbuffer is one is really needed.

Unless we directly run synthesis in the jack callback, I see no way to avoid
the ringbuffer. And there are good reasons against running the engine in the
jack callback, namely that jack callback code is supposed to be hard RT.

In the jack callback: no locks, no malloc, no other blocking operations...

After looking into it again, jack ringbuffer is technically not safe to use,
because it doesn't use atomics/memory barriers. Besides the usual
non-typesafety issues in the API.

C++11 has atomics with a well-defined cross thread memory visibility.  I think
my implementation should be safer than jack ring buffer, due to the guarantees
C++11 atomics - which I use - provide.

There is only one alternative I found, that could possibly used instead of
my own ringbuffer:

boost::lockfree::spsc_queue

but as we don't depend on boost yet, I am not sure whether we want to use that
as ringbuffer.

In any case the implementation I have provided works, and I'll keep it for now.

   Cu... Stefan

> IIRC, the old ring buffer code we had went into birnet, then rapicorn,
> then rcore and because it got no uses into rcore/tests and in the end
> was removed a year or so ago.
> The final removal was due to non-trivial bugs in the ring buffer code
> found by the gcc/clang thread sanitizers, see rapicorn's
>       --enable-debug=tsan
> option. (Not sure if that got ported to beast yet)
>
> On 28.06.2017 13:46, Stefan Westerfeld wrote:
> >    Hi!
> >
> > Now that I ported jack-driver to the new beast (jack-driver branch),
> >
> >   https://github.com/swesterfeld/beast/issues/6
> >   https://github.com/swesterfeld/beast/tree/jack-driver
> >
> > I wonder I should eliminate my ringbuffer implementation which
> > currently lives in the driver code and use jack_ringbuffer instead.
> >
> > Pro:
> >  - we get rid of hand written, non trivial lock-free ringbuffer code
> >    and use a standard solution, which is well-tested and used elsewhere
> >
> > Con:
> >  - we don't have a ringbuffer for other parts of the beast code if
> >    jack is not available
> >
> > I tend to using jack_ringbuffer, it would make the driver easier to maintain. I
> > didn't try porting that yet, but I believe it is feasible.
> >
> >    Cu... Stefan
>
> -- 
> Yours sincerely,
> Tim Janik
>
> https://testbit.eu/timj/
> Free software author.
> _______________________________________________
> beast mailing list
> beast gnome org
> https://mail.gnome.org/mailman/listinfo/beast

-- 
Stefan Westerfeld, http://space.twc.de/~stefan