23 Jun
2006
23 Jun
'06
3:14 a.m.
Paul Davis:
On Thu, 2006-06-22 at 18:37 +0200, Benjamin Fabricius
wrote:
Not really. I think vstserver V0.0.1 or something ran everything in one
process. But I changed it quickly because if one plugin crashed, the whole
server went down as well, I'm not sure how bugfree v0.0.1 is though. It
might still work...
Hi all,
ive made some more progress on the madi vst server.
now ive got following problem. i am planing on being
able to run a large amount of plugins as i route 64 channels
of audio i/o.
fst seems to start a dedicated wine-preloader process for every
plugin that is loaded. this causes my ram to decimate very
quickly and thats one thing i dont have a lot of. 512MB - Ramdisk
(running kind of an embedded system).
after starting 15 - 17 plug instances there is none
left obviously. is there a possibility of using only one shared wine
process or does anybody out there know a different work around to this
problem?
kjetil's vstserver design works this way.
23 Jun
23 Jun
8:11 a.m.
New subject: [linux-audio-user] Re: fst-1.8 triggers wine-preloader processes using a lot of ram
Am Donnerstag, den 22.06.2006, 22:14 -0700 schrieb Kjetil S. Matheussen:
i thought vstserver was an obsolete approach...
--
-------------------
Benjamin Fabricius
German Student
Lawo AG
not totally sure what you're doing, but keep in
mind that Muse put a >
lot
of effort into making this work reliably across many plugins. don't
expect to see this happen "easily".
what i want and am doing is to route a maximum of 64 audio channels
through various plugins by using jacks routing matrix and then output
these again. the plugins are being loaded by fst. ive ran some latency
and signal tests on this system to check if the system is stable and bit
transparent and also estimated s/n, distortion factor etc and everything
is working to my satisfaction thanks to having built this system using a
more or less embedded linux. this seems to offer enough cpu ressources
for this setup to work (dedicated and thus) reliably with up to 18 (max.
possible plugs to this date) plugins without getting xruns or other
artifacts. so thats what im doing. yesterday while testing suddenly
qjackctl crashes.. due to an out of memory fault. ive got
512MB ram minus the space for my ramdisk. a quick look into top now saw
me confronted with a large list of wine-preloader processes using up to
10% of my memory each (!).
i was not doubting the effort invested in making plugins run stable with
fst or Muse etc. i merely thought it was worth finding out if any one
has had these difficulties in an environment with similar low
ressources.
as a matter of fact i would actually like to stick with fst because i am
surprised it works as reliably as i have experienced.
kjetil's vstserver design works this way.
Not really. I think vstserver V0.0.1 or something ran
everything in one
process. But I changed it quickly because if one plugin crashed, the whole
server went down as well, I'm not sure how bugfree v0.0.1 is though. It
might still work...
on the other hand this seems to be an issue also. what i
certainly dont
want is the server going down if one plugin throws in the towel...
so im still thinking about the possibilities ive got and the pros and
cons. any advice out there? or reports on how you got your system to
work the way you wanted with many plugins?
ive also got another question. havent gone through the code looking for
this yet so pardon this question of mine.
id like to change plugin user parameters using the vst api funtions
(setParameter(..) etc). is there a way i could extend fsts functionality
in the sense of an interface accepting these values an then passing them
on through fst and into the plugin instance? im more from a oop
backround so sorry about this abstract idea ;-)
7:03 p.m.
New subject: [linux-audio-user] Re: fst-1.8 triggers wine-preloader processes using a lot of ram
On Fri, 2006-06-23 at 12:11 +0200, Benjamin Fabricius wrote:
Am Donnerstag, den 22.06.2006, 22:14 -0700 schrieb
Kjetil S. Matheussen:
Try lowering RLIMIT_STACK from 8MB to 256KB or something (the default is
set in /etc/security/limits.conf). Heavily mulithreaded processes +
mlockall() wastes a LOT of memory for thread stacks.
The latest SVN Jack solves this problem by setting the thread stack size
itself.
Lee
not totally sure what you're doing, but keep
in mind that Muse put a >
lot
of effort into making this work reliably across many plugins. don't
expect to see this happen "easily".
what i want and am doing is to route a maximum of 64 audio channels
through various plugins by using jacks routing matrix and then output
these again. the plugins are being loaded by fst. ive ran some latency
and signal tests on this system to check if the system is stable and bit
transparent and also estimated s/n, distortion factor etc and everything
is working to my satisfaction thanks to having built this system using a
more or less embedded linux. this seems to offer enough cpu ressources
for this setup to work (dedicated and thus) reliably with up to 18 (max.
possible plugs to this date) plugins without getting xruns or other
artifacts. so thats what im doing. yesterday while testing suddenly
qjackctl crashes.. due to an out of memory fault. ive got
512MB ram minus the space for my ramdisk. a quick look into top now saw
me confronted with a large list of wine-preloader processes using up to
10% of my memory each (!).
i was not doubting the effort invested in making plugins run stable with
fst or Muse etc. i merely thought it was worth finding out if any one
has had these difficulties in an environment with similar low
ressources.
as a matter of fact i would actually like to stick with fst because i am
surprised it works as reliably as i have experienced.
6534
days inactive
6534
days old
linux-audio-user@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Benjamin Fabricius -
Kjetil S. Matheussen -
Lee Revell