|
From: Robert J. <rob...@da...> - 2003-10-28 13:57:59
|
Tuesday 28 October 2003 14.22 skrev be...@ga...: ... > > > - it segfaults when ctrl-c:ing out of the app. > > probably due to the incorrect stopping of threads when the CTRL-C handler > is called, not a serious issue and probably very easy to fix. > As said it would be more serious if linuxsampler segfaulted during playing. > :-) yeah, it's no big deal ;) > > > - on my system i get mlockall failures all the time, regardless of the > > size of > > the gig file and such... how much mem does LS allocate? (I've got 512mb > > so it > > > > should work rather well I think. I can run debug compiled-muse together > > with > > > > jack with no problems, which both do mlockall and occupy lots of > > memory...) > > see diskthread.h: > #define STREAM_BUFFER_SIZE 131072 > #define MAX_INPUT_STREAMS 64 > > this means we can have max 64 disk streams (each voice if streamed from > disk exactly needs one stream). > We are talking about 16bit samples (2bytes) thus > the streams occupy > MAX_INPUT_STREAMS*STREAM_BUFFER_SIZE*2 > > this is not an extremely high amount, in the above case 16MB Definately not alot.... it may be that my machine has severely fragmented memory, I'll try rebooting it tonight.. <lots of interesting stuff shamelessly deleted> > Even if there are already relatively cheap 64bit x86 boxes around, most > notably the AMD Opteron / Athlon 64, Windows cannot use its full > capabilities because the 64bit support is not it yet. > Read this and you will see that Windows XP on AMD 64bit CPUs will take long > long time to become a viable option: (a very bumby road I would say) > http://www.pcworld.com/news/article/0,aid,112749,pg,6,00.asp > > On the other hand Linux already runs on AMD 64bit CPUs and linuxsampler is > 64bit compatible too. > This means we can beat the windows sampler at their own game: linuxsampler > already runs on performant 64bit boxes and what's more important we can > handle much bigger amounts of RAM which is crucial for those wanting to > load many samples at the same time. > I guess once linuxsampler's engine is production ready and can play > preexisting libraries correctly it will turn up on the windows people > radarscreens, I assume even those using the windows samplers professionally > because those are the people that need these monster installations with > dozen, even hundreds of GBs worth of samples. This could become a real killer feature! :) > And I don't even touched the fact that linuxsampler could be clustred to > provide sampler farms that can render thousand of voices and pipe them > back in real time over ethernet without requiring expensive audio cards, > midi interfaces etc for each cluster slave. Hehe, okay, but I think you should save that for version 2 ;). > > The things I miss are (probably mostly on the todo already) > > > > - gui (not strictly necessary) > > I have half finished a simple load&play GUI (load samples, assign them > to midi channels and start playing, plus the GUI permits you to set > basic settings like number of voices, RAM preload sizes etc, shows you > activity and real time voice count etc). > As I stated before linuxsampler is remotely controllable via TCP/IP which > means the GUI can run on a different box and even on a different platform. > What I am working on now is the remote control protocol which is a simple > API that can be used by anone so anyone can build their favorite kind of > remote control application. > It can be a GUI, a text based application, a script, hardware buttons etc. > The default GUI I will provide is written using the Qt library because of > its portability. This will allow to run the GUI frontend on Windows and > Mac too. > This is because I'm assuming sooner or later we will see those linuxsampler > clusters remote controlled by Windows PCs or Macs :-). > Plus do not forget separating the frontend from the engine forces you > to follow certain rules during coding which leads to a better quality > of the code and helps to isolate errors and performance problems. sounds great! > > > - jack output > > Of course. We will go as far that linuxsampler will not only export > the main output (where all vocies will be mixed too) but single > midi channel mix buffers which you can send to jack unprocessed > and process the channels with your own FXes or record the tracks > into eg ardour for further editing. > But for now we only support direct ALSA out because we must first > iron out potential latency problems. > (if you put jack into the game then you cannot easily figure out > if it's linuxsampler's or jack's fault). > Divide et impera is the keyword here :-) > > > - soundfont support, for now I'm perfectly happy with gig support, I > > wonder how hard it would be to add soundfont support though..? > > Well soundfont offers quite some modulation possibilities > (Peter Hanappe and Josh Green know this better than anyone). > I guess for now if you want SF2 it is better to use fluidsynth. > SF2 is IMHO a bit limited and linuxsampler aims at the professional > sampling domain so our priority is to make .GIG working. (at a later stage > we will try to add 24bit sample in Halion / Kontakt formats too). yeah, soundfonts may not have the same professional feel, there are lots of tome though, and some of the new ones allocate quite a lot of memory. > > Or alternatively when our GIG engine will be complete you can try to > convert your SF2 files using a conversion program like cdxtract > http://www.cdxtract.com (but relatively expensive $150). > Or better, integrate the fluid engine to linuxsampler :-) yeah, I was thinking along those lines :) but I have no idea if it would be feasible. Josh are you here somewhere? Enlighten me :) > > > - hmmm I think I ran it as an ordinary user (with pretty good results), > > it occurs to me that SCHED_FIFO should not be available then. LS uses > > SCHED_FIFO > > > > right? Should it complain if it can't set it? (this may be a > > misconception of > > > > mine though) > > In theory it should complain: > if (sched_setscheduler(0, SCHED_FIFO, &schp) != 0) { > perror("sched_setscheduler"); > return -1; > } > > anyway sched_setscheduler() is deprecated because for threads one should > use pthread_attr_init() to set priorities. > I heard rumors that sched_setscheduler() does not work correctly on > recent threading libraries but I cannot confirm it. It may be all my fault, I may just as well have run as root out of habit, I run most audio stuff as root... > > > ---- > > And finally, a wish. I think this mailinglist is too quiet, it's hard to > > know > > > > if there is any activity at all. > > > > May I propose that you guys start announcing cvs checkins on this list? > > We will certainly announce new (relevant) CVS checkins on the list > (manually). > Regarding myself I'm working on the GUI/remote control protocol and it will > take some time to make it work well, document etc so I guess I will not > check in new stuff before 1-2 weeks. Perhaps Christian will add some stuff > meanwhile and I'm sure he will announce it on this mailing list. Release early, release often :) repeat the mantra. Though I'm happy if it atleast compiles ;) /Robert |