On 10/10/2013 08:37 PM, Lars Luthman wrote: > I would just bypass the LV2 host altogether and use shared memory to get > the audio data to the GUI. This is what the DSSI plugin does. This means > that it will not work if the plugin and the GUI are running on separate > machines, but that seems to be pretty rare.
These days it not as rare as it used to be. A scope is just 1D - say 1024 pixels width -> 1K values that need to be transmitted from the back-end to the UI. No need to use shared memory, really. The only reason for using shmem would be transmitting _all_ the raw audio-data for upsampling in the UI-thread[1]. But even so, 1.5 Mbit/sec is nothing these days. Besides, up/down-sampling requires a ringbuffer anyway, and shmem won't buy you anything. Message-passing (LV2 Atom messages) can go directly into the UI's ringbuffer (no extra copy) and will allow the UI to run remotely. 2c, robin [1] Upsampling can be CPU heavy, but since it's for display only, it should not cause DSP load -> delegate to UI-thread. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev