[Jack-Devel] Avoiding spinlocks in a parallel sequencer

[Robin Gareus]

[excuse for continuing top-posting]

Mark McCurry (current zynaddsubfx maintainer) is in the process of a 
rewrite.
All the semaphores are gone and midi-parsing + synthesis is done 
in-process
(either jack-callback or LV2-run) and GUI communication is completely 
separated via OSC.



On 2015-04-09 15:00, Paul Davis wrote:
> Speaking entirely personally, I think this design is just plain nuts. 
> I
> know there are some JACK-ecosystem developers who disagree with me, 
> but I
> think that using JACK clients for this purpose is just wrong and is 
> pushing
> the design scope for JACK.
>
> What you're doing is precisely what a plugin architecture was 
> intended to
> address, and I really think you'd be better off implementing your own 
> audio
> graph with plugins. Of course, that requires a version of zyn that 
> can run
> as a plugin, which I think has been discussed but I don't think it 
> was
> every implemented fully.
>
> On Thu, Apr 9, 2015 at 2:01 AM, Johannes Lorenz 
> <johannes89 at mailueberfall.de
>> wrote:
>
>> Hi,
>>
>> > I try to understand your plan:
>> >
>> > simple data flow example:
>> >
>> > zynaddsubfx_1_output
>> >
>> >           V
>> > sequencer_client_1_input
>> >
>> >           V
>> > sequencer_input_ringbuffer
>> >
>> >           V
>> > (sequencer processing stuff)
>> >
>> >           V
>> > sequencer_output_ringbuffer
>> >
>> >           V
>> > sequencer_client_output
>> >
>> >           V
>> > system_client_input(hardware output)
>>
>> Your picture is indeed correct. To add some more examples:
>>
>>   * Something like this is also possible
>>
>>         sequencer_input_ringbuffer_1     
>> sequencer_input_ringbuffer_2
>>                 V                                V
>>         plus (i.e. addition of sound-waves)
>>                 V
>>         plus_effect_ringbuffer
>>
>>   * The part that you labeled "(sequencer processing stuff)" might 
>> be
>> filled with:
>>
>>                 V
>>         peak_controller_effect        some lfo generator
>>                 V (lfo)                       V (lfo)
>>         zynaddsubfx_2_volume_input    
>> zynaddsubfx_2_filter_freq_input
>>                 V
>>         (zynaddsubfx_2)
>>                 V
>>         zynaddsubfx_2_output
>>                 V
>>         sequencer_client_2_input
>>                 V
>>
>> > Maybe also what you envision to happen in which thread or which
>> > callback?
>>
>> Let's take the second example. zynaddsubfx itself is in another 
>> process,
>> so we don't need to run this at all. For feeding each ringbuffer 
>> from zyn,
>> I planned to use a separate jack client. E.g., if process() of
>> sequencer_client_1_input is being called, it simply copies "nframes" 
>> into
>> sequencer_input_ringbuffer.
>>
>> Everything that now remains (e.g. lfo generator, 
>> peak_controller_effect,
>> sending input to zynaddsubfx_2) is done by a process() callback of
>> sequencer_client_output. I call this one the master jack client.
>>
>> About the problem:
>>
>> A point where I think spinlocks can't be avoided would be, e.g., 
>> reading
>> from sequencer_output_ringbuffer. The sequencer's master jack client 
>> would
>> need to do that in process(), but it can not guess when the 
>> ringbuffer
>> reader from sequencer_client_2_input has even started to feed the
>> ringbuffer.
>>
>> > Do you want to do some signal processing in your sequencer or 
>> would it
>> > be ok to delegate this to other jack clients? (may be easier)
>>
>> Hopefully you got it from the explenations above: the master jack 
>> client
>> would do this right now, as I planned. Other ideas will be fine, 
>> too.
>> Though, I guess, for "some lfo generator", e.g., a separate jack 
>> client
>> would be overkill, as this generator simply does, e.g., f(x) = 
>> sin(x).
>>
>> _______________________________________________
>> Jack-Devel mailing list
>> Jack-Devel at lists.jackaudio.org
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>