Subject: Re: [linux-audio-dev] No IPC in LADSPA?!
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Mon Mar 27 2000 - 21:36:39 EEST
I was disappointed too when I found out. the workaround would be to
write a proxy host that would take care of IPC... I was hoping to find
sort of X for sound - network transparent communication protocol that
would allow you to pass (stream) various kinds of data... is there any
such project out there? I know there are specific streaming solutions
but I am most interested in combination of network transparent streaming
with audio processing (kinda like network transparent LADSPA)
note that networking does'nt have to add that much overhead if you're
not using it, for example X uses IPC, but if you're on the same host it
cicumvents it (without clients having to care for that).
erik
David Slomin wrote:
>
> Whoa!
>
> Catching up on this weekend's LAD postings, I just became aware that
> LADSPA will not support IPC. I personally dislike plugins and prefer
> standalone apps communicating over IPC whereever possible, since it
> means more freedom for the end-user to mix and match what he
> personally considers to be the best at each task. Keep in mind that
> my primary interest is in low bandwidth control messages (think MIDI),
> not signals, so standard IPC mechanisms normally __do__ have low
> enough latency for me. Thus LADSPA has lost a lot of interest for me.
>
> That leaves MuCoS which, as it has been mentioned, __does__ support
> IPC. However, MuCoS is inherently a batch system, not streaming.
> By this, I mean that it takes queues of timestamped events and
> processes them in chunks, rather than delivering non-timestamped
> events individually, as fast as it can.
>
> What is the correct solution for folks like me who want to stream
> non-timestamped events between different processes ASAP (not
> guaranteed hard realtime, but as fast as possible)?
>
> Div.
>
> --
> David Slomin, Engineer mailto:david.slomin_AT_av.com
> AltaVista Business Solutions http://solutions.altavista.com/
> RFC 822 plaintext email strongly preferred except for attachments
This archive was generated by hypermail 2b28 : Mon Mar 27 2000 - 22:23:48 EEST