Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity

[Robert J. <rob...@da...>]

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