Re: [linux-audio-dev] Re: [vst-plugins] Plugin server
On Sun, 2002-12-08 at 16:14, Kai Vehmanen wrote: > On Sun, 8 Dec 2002, Paul Davis wrote: > > > you also haven't addressed kernel scheduling issues; the context > > switch doesn't happen till the kernel has decided what task is going > > to run next. if it picks the wrong one, for whatever reason, then > > you/we lose. right now, it picks the wrong one too often, even with > > SCHED_FIFO+mlockall. > > Btw; have you tried the O(1) scheduler? It has a number of interesting > charasteristics from an audio app developer's pov [1]: I tried it (using the Con Kolivas patches on top of 2.4.20). I still get xruns in jackd, although that particular patchset (plus the drm lowlat patches) seems to keep them to more reasonable values at least in a short test I just did. I managed to also hang the machine, after running jackd + qjackconnect + freqtweak + ams for a while I got greedy and started ardour - created a new session and when I went to connect things in qjackconnect the machine stopped... it still responds to alt-sysrq-b. BTW, with latest versions of alsa the hanging problems seems to happen less frequently so it may be some interaction between alsa and the kernel (hangs do not seem to happen in 2.4.19). Besides that, it looks like the O(1) scheduler is less responsive to user interaction in certain cases. While doing an alsa driver compile the mouse was freezing for fractions of a second at a time (this was during the depend phase, actually compiling the modules did not have that effect). [anyone out there has a patch to schedutils to make them work with the O(1) scheduler?, mine just report all tasks as Other] -- Fernando
Re: [linux-audio-dev] Re: [vst-plugins] Plugin server (Re: [vst-plugins]Re: [a bit OT] gcc as a cross compiler for VST?
On Sun, 8 Dec 2002, Paul Davis wrote: > >> >I'm not talking about jack tasks, I'm talking about doing a simple > >plug-in > >> >task inside a standalone program, the way the vst server works. > >> > >> i don't understand how the vst server works. perhaps you can explain > >> it. > > > >Its just simple one to one process request/processing/answer. No mixing > >or synchronising. > > in other words, a lot like JACK :) one plugin per JACK client. no real > difference, i would guess. > Really? I thought all jackclient sounddata exchange went thru the jackd program, to get everything synchronized? --
Re: [linux-audio-dev] Re: [vst-plugins] Plugin server
On Sun, 8 Dec 2002, Paul Davis wrote: > you also haven't addressed kernel scheduling issues; the context > switch doesn't happen till the kernel has decided what task is going > to run next. if it picks the wrong one, for whatever reason, then > you/we lose. right now, it picks the wrong one too often, even with > SCHED_FIFO+mlockall. Btw; have you tried the O(1) scheduler? It has a number of interesting charasteristics from an audio app developer's pov [1]: - RT-scheduling is, too, O(1) (less cache use, quicker context switches...) - RT-scheduling is separated from non-RT scheduling - perfect SMP-scalability (no shared run-queue lock) And of course, as O(1) is under active development (in 2.5, in 2.4-ac and patches for latest 2.4 kernels), a possible bug in SCHED_FIFO semantics might receive kernel-hacker interest. ;) Do you have any simple test cases to reproduce the problem... only with ardour+jackd or perhaps also simpler setups like jackd+capture_client or some such? [1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.0/0810.html -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Re: [vst-plugins] Plugin server (Re: [vst-plugins] Re: [a bit OT] gcc as a cross compiler for VST?
>Yupp, I see. I get a 7 percent penalty compaired to doing >the same just in one process. right. now try it with 8 different processes, all of them touching enough (different) data to invalidate a random selection of about 80% of the cache. or better yet, just take our word for it that the cost of the context switch is significant. you also haven't addressed kernel scheduling issues; the context switch doesn't happen till the kernel has decided what task is going to run next. if it picks the wrong one, for whatever reason, then you/we lose. right now, it picks the wrong one too often, even with SCHED_FIFO+mlockall. >> >I'm not talking about jack tasks, I'm talking about doing a simple >plug-in >> >task inside a standalone program, the way the vst server works. >> >> i don't understand how the vst server works. perhaps you can explain >> it. > >Its just simple one to one process request/processing/answer. No mixing >or synchronising. in other words, a lot like JACK :) one plugin per JACK client. no real difference, i would guess. --p
Re: [linux-audio-dev] Re: [vst-plugins] Plugin server (Re: [vst-plugins]Re: [a bit OT] gcc as a cross compiler for VST?
On Sun, 8 Dec 2002, Paul Davis wrote: > Kjetil and i have been boring the VST crew to death. so we took it > here :) > > >> because when running a real-time low-latency audio system, the cost of > >> context switches is comparatively large. if you've got 1500usecs to > >> process a chunk of audio data, and you spend 150usecs of it doing > >> context switches (and the cost may be a lot greater if different tasks > >> stomp over a lot of the cache), you've just reduced your effective > >> processor power by 10%. > >> > >I dont believe you. I just did a simple context-switching/sockets > >test after I sent the last mail. And for doing 2*1024*1024 context > >syncronized switches between two programs, my old 750Mzh duron uses 2.78 > >seconds. That should about 1.3usecs per switch or something. By > > you didn't touch much of the cache, did you? Eh. No. :) > it doesn't matter how fast the actual switch is if each task wipes out > the L1 and L2 cache, forcing a complete refill of the cache, reload of > the TLB, etc. etc. the cost of a context switch is not just a register > store+restore. the cost of it depends on what has happened since the > last context switch. > > try your "simple context switch test" with a setup in which each task > writes to about 256kB of memory. Yupp, I see. I get a 7 percent penalty compaired to doing the same just in one process. > we measured this extensively on LAD a year or two ago. both myself and > abramo and some others did lots of tests. we plotted lots of > curves. the results were acceptable but not encouraging. yes, faster > processors will decrease the time it takes to save and load the > registers. but just as for much DSP code these days, other issues > often dominate over raw CPU speed; the slow downs caused by the TLB > being invalidated as a result of switching address spaces and the > cache invalidation (for the same reason) are dramatic. Going to dig into the discussion. This was very interesting. > >I'm not talking about jack tasks, I'm talking about doing a simple plug-in > >task inside a standalone program, the way the vst server works. > > i don't understand how the vst server works. perhaps you can explain > it. Its just simple one to one process request/processing/answer. No mixing or synchronising. --
