Menu
▾
▴
linuxsampler-devel
|
From: <be...@ga...> - 2003-11-15 17:39:14
|
Christian told me that he wants to begin to implement the event system but I'd prefer that we fix a few bugs first, otherwise it will harder and harder to find them. - LS crashes when the maximum voice count is achieved - when you hold a voices till the sample terminates you hear a continuing high pitched noise. I guess this is the buffer of the voice still being mixed to the sum buffer. Plus in that case the CPU usage goes up. - sometimes a voice gets cut off and only the RAM part is played. So folks (particularly Christian) check out the latest CVS and start finding the bugs. (I have no time for the next few days)_ regarding the event system I will post a message tonite or tomorrow because I have a few questions for David how to optimize the system. regarding the polyphony of my VIA with crappy FPU machine: I tested a piano .MID file that makes heavy use of sustain pedal. My box is able to keep up with peaks of 100 stereo voices. = 200 voices expressed gigasampler terminology :-) Better not imagine what an Athlon 3000 can deliver :-) So basically it means that a mini-itx VIA box has enough horsepower to ne turned into a high polyphony, high quality piano expander. :-) Let me know (on the list) if you find the bugs mentioned above, and then let's start with the event sysyem. cheers, Benno http://www.linuxsampler.org ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-11-15 19:42:52
|
Hi Benno, I built CVS this morning and gave it a shot. Sustain is working. Still big clicks on each key release, so I guess no release samples or default envelope yet. (I think that's expected, but just in case it's supposed to be there I'll report it's not working for me.) This version seems to load very much faster for me. Have you done something in that area? I am not hearing the high pitched noise on my system, and I'm never getting very high on CPU usage. I never see about about 3% on gkrellm even at close to 64 voices. I do see the segfault when I get to 64 voices. (I thought LS wasn't going to have a voice limitation?) I am also seeing a stranger, and different segfault. I hold the sustain pedal and just arpeggiate a C major chord and let the voices build up, but only to about 55-60 voices. Next I hold the sustain pedal and let the voice count decay back to 0. Now, with the sustain pedal still held, I start the arpeggio again, it segfaults immediately and differently: The first is a voice overload segfault: Wizard root # linuxsampler --numfragments 2 --gig /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\ Grand\ Version\ 2.2.gig Loading gig file...OK LinuxSampler initialization completed. Segmentation faultms: 060 This one is the other segfault: Wizard root # linuxsampler --numfragments 2 --gig /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\ Grand\ Version\ 2.2.gig Loading gig file...OK LinuxSampler initialization completed. Segmentation faultms: 014 Wizard root # Request: Could you possibly put the plughw:0 hack instructions in a README that gets downloaded with the code? Thanks, Mark On Sat, 2003-11-15 at 09:39, be...@ga... wrote: > Christian told me that he wants to begin to implement the event system > but I'd prefer that we fix a few bugs first, otherwise it will harder and > harder to find them. > > - LS crashes when the maximum voice count is achieved > - when you hold a voices till the sample terminates you hear a continuing high > pitched noise. I guess this is the buffer of the voice still being mixed > to the sum buffer. Plus in that case the CPU usage goes up. > - sometimes a voice gets cut off and only the RAM part is played. > > So folks (particularly Christian) check out the latest CVS and start finding > the bugs. (I have no time for the next few days)_ > > regarding the event system I will post a message tonite or tomorrow because > I have a few questions for David how to optimize the system. > > regarding the polyphony of my VIA with crappy FPU machine: > I tested a piano .MID file that makes heavy use of sustain pedal. > My box is able to keep up with peaks of 100 stereo voices. > = 200 voices expressed gigasampler terminology :-) > Better not imagine what an Athlon 3000 can deliver :-) > So basically it means that a mini-itx VIA box has enough horsepower > to ne turned into a high polyphony, high quality piano expander. > :-) > > Let me know (on the list) if you find the bugs mentioned above, and > then let's start with the event sysyem. > > cheers, > Benno > http://www.linuxsampler.org > > > ------------------------------------------------- > This mail sent through http://www.gardena.net > > > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: <be...@ga...> - 2003-11-15 21:57:41
|
Scrive Mark Knecht <mar...@co...>: > Hi Benno, > I built CVS this morning and gave it a shot. Sustain is working. > Still big clicks on each key release, so I guess no release samples or > default envelope yet. (I think that's expected, but just in case it's > supposed to be there I'll report it's not working for me.) No envelopes implemented yet. So click is normal. > > This version seems to load very much faster for me. Have you done > something in that area? It's probably because I set the preload size to 32k samples (instead of the previous 64k). This is because I was developing on a 256MB box which was not able to load a big piano GIG with 64k preloading. The fun thing is that even with this relatively short preloading time. (0.7sec). the heavy sustain piano MIDI file was able to play 100 stereo voices without getting dropouts. I heard in NI Kontakt for stable operation sometimes you need 600KB (150K samples) of preload ! :-) > > I am not hearing the high pitched noise on my system, > and I'm never > getting very high on CPU usage. I never see about about 3% on gkrellm > even at close to 64 voices. Cool, for completeness use 'top' too its CPU usage measurement is convincing IMHO (look at the CPU usage of the linuxsampler process) > > I do see the segfault when I get to 64 voices. (I thought LS wasn't > going to have a voice limitation?) it's just a define, no limitation :-) for example for 256 voices define: audiothread.h:#define MAX_AUDIO_VOICES 256 diskthread.h:#define MAX_INPUT_STREAMS 256 and recompile. You could try to load up LS to 256 voices and see how much CPU it uses. but in that case increase the preload size too audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536 > > I am also seeing a stranger, and different segfault. I hold the > sustain pedal and just arpeggiate a C major chord and let the voices > build up, but only to about 55-60 voices. Next I hold the sustain pedal > and let the voice count decay back to 0. Now, with the sustain pedal > still held, I start the arpeggio again, it segfaults immediately and > differently: Keep in mind that there are linked lists holding the current on notes (voice) and the currently sustained notes. When a voice fades out due to the sample ending the corresponding voice is not yet removed from those lists. Thus the next time you press a key (or relase the pedal) it could crash the engine because it is accessing to voices used twice etc. It's a known bug but the important thing was getting sustain working for now. > > Request: Could you possibly put the plughw:0 hack instructions in a > README that gets downloaded with the code? Yes we should add a --alsadevice option too. Plus Christian on his delta 1010 was not able to make plughw work so probably we need a special hw:0 routine for his delta (otherwise LS does not work on his workstation connected to the midi keyboard). cheers, Benno http://www.linuxsampler.org ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-11-15 23:16:26
|
On Sat, 2003-11-15 at 13:57, be...@ga... wrote: > Scrive Mark Knecht <mar...@co...>: > > I am not hearing the high pitched noise on my system, > > and I'm never > > getting very high on CPU usage. I never see about about 3% on gkrellm > > even at close to 64 voices. > > Cool, for completeness use 'top' too its CPU usage measurement is > convincing IMHO (look at the CPU usage of the linuxsampler process) Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even banging away on it, but being careful not to use too many notes, it never gets above 5% on my machine. I don't think this means much, but it's a data point. > it's just a define, no limitation :-) > for example for 256 voices define: > > audiothread.h:#define MAX_AUDIO_VOICES 256 > diskthread.h:#define MAX_INPUT_STREAMS 256 > > and recompile. > > You could try to load up LS to 256 voices and see how much CPU > it uses. > but in that case increase the preload size too > audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536 Tried it. The program dies somewhere around 120-140 voices complaining: Wizard root # linuxsampler --numfragments 2 --gig /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\ Grand\ Version\ 2.2.gig Loading gig file...OK WARNING, can't mlockall() memory!: Cannot allocate memory WARNING, can't mlockall() memory!: Cannot allocate memory LinuxSampler initialization completed. WARNING, can't mlockall() memory!: Cannot allocate memory ERROR: SustainedKeyPool FULL ! exiting Wizard root # The code in audiothread.cpp that generates this message says /FIX ME/ so I guess you need to. ;-) Before it crashed I was still only seeing about 4-5% on the main LS thread. I cannot watch them all and play at the same time. > > Keep in mind that there are linked lists holding the current on notes (voice) > and the currently sustained notes. > When a voice fades out due to the sample ending the corresponding voice > is not yet removed from those lists. > Thus the next time you press a key (or relase the pedal) it could > crash the engine because it is accessing to voices used twice etc. > It's a known bug but the important thing was getting sustain working for > now. OK. Let me know when you've fixed it and I'll look again. > > > > > > Request: Could you possibly put the plughw:0 hack instructions in a > > README that gets downloaded with the code? > > Yes we should add a --alsadevice option too. > Plus Christian on his delta 1010 was not able to make plughw work > so probably we need a special hw:0 routine for his delta > (otherwise LS does not work on his workstation connected to the > midi keyboard). > ;-) Well, add Jack support while you're at it. ;-) But, seriously, we all know this needs to be a Jack device, doesn't it? Is it difficult to make the change? |
|
From: Christian S. <chr...@ep...> - 2003-11-16 02:04:23
|
Es geschah am Sonntag, 16. November 2003 00:15 als Mark Knecht schrieb: > On Sat, 2003-11-15 at 13:57, be...@ga... wrote: > > Scrive Mark Knecht <mar...@co...>: > > > I am not hearing the high pitched noise on my system, > > > and I'm never > > > getting very high on CPU usage. I never see about about 3% on gkrellm > > > even at close to 64 voices. > > > > Cool, for completeness use 'top' too its CPU usage measurement is > > convincing IMHO (look at the CPU usage of the linuxsampler process) > > Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even > banging away on it, but being careful not to use too many notes, it > never gets above 5% on my machine. I don't think this means much, but > it's a data point. Benno is using a compressed gig whereas you most probably are using a normal one. That's the reason for the cpu usage difference. > > You could try to load up LS to 256 voices and see how much CPU > > it uses. > > but in that case increase the preload size too > > audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536 > > Tried it. The program dies somewhere around 120-140 voices complaining: > > Wizard root # linuxsampler --numfragments 2 --gig > /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\ > Grand\ Version\ 2.2.gig > Loading gig file...OK > WARNING, can't mlockall() memory!: Cannot allocate memory > WARNING, can't mlockall() memory!: Cannot allocate memory That's a sign of low free memory when it's unable to lock it. > LinuxSampler initialization completed. > WARNING, can't mlockall() memory!: Cannot allocate memory > ERROR: SustainedKeyPool FULL ! exiting > Wizard root # > > The code in audiothread.cpp that generates this message says /FIX ME/ so > I guess you need to. ;-) Actually exiting at that point doesn't make sense anyway Benno, so I'll remove it. > > Keep in mind that there are linked lists holding the current on notes > > (voice) and the currently sustained notes. > > When a voice fades out due to the sample ending the corresponding voice > > is not yet removed from those lists. > > Thus the next time you press a key (or relase the pedal) it could > > crash the engine because it is accessing to voices used twice etc. > > It's a known bug but the important thing was getting sustain working for > > now. > > OK. Let me know when you've fixed it and I'll look again. I will fix that. > > > Request: Could you possibly put the plughw:0 hack instructions in a > > > README that gets downloaded with the code? > > > > Yes we should add a --alsadevice option too. > > Plus Christian on his delta 1010 was not able to make plughw work > > so probably we need a special hw:0 routine for his delta > > (otherwise LS does not work on his workstation connected to the > > midi keyboard). plughw works now with my Delta 1010; it wasn't plughw itself but the combination of alsa calls that preceded the snd_pcm_open() call. I will implement automatic fallback to plughw if the sound card lacks to support one the parameters. I will print out a warning in that case and this way no hack or additional parameter is needed. Anybody against that? > ;-) Well, add Jack support while you're at it. ;-) > > But, seriously, we all know this needs to be a Jack device, doesn't it? > Is it difficult to make the change? At least not on my priority list at the moment (even though it wouldn't be much work). But if anybody has the time and will for it, just place the jack code into audioio.cpp and don't forget to send us your patch! :) CU Christian |
|
From: Mark K. <mar...@co...> - 2003-11-16 03:34:49
|
On Sat, 2003-11-15 at 18:03, Christian Schoenebeck wrote: > Es geschah am Sonntag, 16. November 2003 00:15 als Mark Knecht schrieb: > > Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even > > banging away on it, but being careful not to use too many notes, it > > never gets above 5% on my machine. I don't think this means much, but > > it's a data point. > > Benno is using a compressed gig whereas you most probably are using a normal > one. That's the reason for the cpu usage difference. OK. > > > > You could try to load up LS to 256 voices and see how much CPU > > > it uses. > > > but in that case increase the preload size too > > > audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536 > > > > Tried it. The program dies somewhere around 120-140 voices complaining: > > > > Wizard root # linuxsampler --numfragments 2 --gig > > /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\ > > Grand\ Version\ 2.2.gig > > Loading gig file...OK > > WARNING, can't mlockall() memory!: Cannot allocate memory > > WARNING, can't mlockall() memory!: Cannot allocate memory > > That's a sign of low free memory when it's unable to lock it. This only popped up when trying to allow 256 voices on 512MB. I will grant you that my GSt machine has 768MB and is only allowed to do 96 voices, so I'm not overly concerned, but I am curious what's driving this. What's the equation for how much memory is required by LS right now? And can't one simply allocate less memory and take a risk of drop outs because we have less of the sample in memory? Or are there hints in the gig file that are telling you what to do? I should try some smaller libraries and see what happens. - Mark |
|
From: <be...@ga...> - 2003-11-17 11:03:02
|
A few notes:
Marks said he gets the SustainedKeyPool full message
I know the reason of the bug:
audiothread.cpp, line 41:
SustainedKeyPool=new RTELMemoryPool<sustained_key_t>(200);
Actually it should be
SustainedKeyPool=new RTELMemoryPool<sustained_key_t>(MAX_AUDIO_VOICES);
Scrive Mark Knecht <mar...@co...>:
Because there can be as much as sustained voices as there are voices.
Mark I suggest you to check out the latest CVS where Christian made
some fixes like deleting the voice from the on/sustained voice list and
other other bug fixed that caused crashed.
Then add the above fix, increase the MAX VOICE/STREAMS defines and
drive it up to 240 voices and show the CPU usage with 'top'.
I'm curious :-)
> >
> > Benno is using a compressed gig whereas you most probably are using a
> normal
> > one. That's the reason for the cpu usage difference.
Yes, plus my CPU is dog slow. So the difference is even more visible.
Actually LS uses a bit a suboptimal method when streaming compressed .GIG files.
Basically the streaming engine decompressed the streams in real time and
is not caching them if you play the same notes.
Perhaps caching would be
>
> OK.
>
> >
> > > > You could try to load up LS to 256 voices and see how much CPU
> > > > it uses.
> > > > but in that case increase the preload size too
> > > > audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536
> > >
> > > Tried it. The program dies somewhere around 120-140 voices complaining:
> > >
> > > Wizard root # linuxsampler --numfragments 2 --gig
> > > /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
> > > Grand\ Version\ 2.2.gig
> > > Loading gig file...OK
> > > WARNING, can't mlockall() memory!: Cannot allocate memory
> > > WARNING, can't mlockall() memory!: Cannot allocate memory
> >
> > That's a sign of low free memory when it's unable to lock it.
>
> This only popped up when trying to allow 256 voices on 512MB. I will
> grant you that my GSt machine has 768MB and is only allowed to do 96
> voices, so I'm not overly concerned, but I am curious what's driving
> this. What's the equation for how much memory is required by LS right
> now?
>
> And can't one simply allocate less memory and take a risk of drop outs
> because we have less of the sample in memory? Or are there hints in the
> gig file that are telling you what to do? I should try some smaller
> libraries and see what happens.
>
> - Mark
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
-------------------------------------------------
This mail sent through http://www.gardena.net
|
|
From: <be...@ga...> - 2003-11-17 11:41:28
|
Scrive Mark Knecht <mar...@co...>: The SustainedKeysPool FULL message is due to audiothread.cpp: line 40: SustainedKeyPool = new RTELMemoryPool<sustained_key_t>(200); you must replace 200 with MAX_AUDIO_VOICES. There can be as much sustaned voices as there are voices. Download the latest CVS where Christian made some fixes that avoid crashes and apply the above change. Then set MAX_AUDIO_VOICES/STREAMS to 256, recompile and try to drive LS to 240-250 voices and look at the 'top' command how much CPU LS consumes. I'm curious :-) > On Sat, 2003-11-15 at 18:03, Christian Schoenebeck wrote: > > Es geschah am Sonntag, 16. November 2003 00:15 als Mark Knecht schrieb: > > > Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even > > > banging away on it, but being careful not to use too many notes, it > > > never gets above 5% on my machine. I don't think this means much, but > > > it's a data point. > > > > Benno is using a compressed gig whereas you most probably are using a > normal > > one. That's the reason for the cpu usage difference. Yes, plus the problems is even more visibile in my case because my CPU is a bit slow. Anyway LS currently uses a method to stream crompressed .GIG files which is a bit suboptimal. Basically no caching of the decompressed stream is performed so the decompressing is performed all the time (in the low priority disk thread). Anyway I'm unsure if caching would buy us anything because those samples are so large that you could only cache small parts and playing dynamic pieces you trigger a large number of the samples contained in the GIG so I guess caching would be only a big coding work with maybe gaining only a few % in terms of absolute performance. Keep in mind that the decompression is performed in the low priority thread which means the audio engine does not get slow down by the streaming task. As long as the CPU is being able to keep up with the load things will be perfectly fine. As said above when playing a real, dynamic (in terms of MIDI velocity) piece even the optimized engine would probably make little use of the caching. > > This only popped up when trying to allow 256 voices on 512MB. I will > grant you that my GSt machine has 768MB and is only allowed to do 96 > voices, so I'm not overly concerned, but I am curious what's driving > this. What's the equation for how much memory is required by LS right > now? The equation is simple: audiothread.h: #define NUM_RAM_PRELOAD_SAMPLES 32768 when you have mono samples, each sample contained in the GIG lib consumes 64KB (32768 x 16bit) in memory. In case of stereo samples its 128KB. diskthread.h:#define STREAM_BUFFER_SIZE 131072 When you define the max number of voices (MAX_AUDIO_VOICES) you consume MAX_AUDIO_VOICES*STREAM_BUFFER_SIZE*2 (2 because samples are 16bit). So in case of 256 voices and the default STREAM_BUFFER_SIZE of 131072 256*131072*2 = 64MB So perhaps these additional 64MB did not fit in your RAM anymore. Keep in mind that the voice buffers are not that big, most of the RAM is consumed by the sample beginnings preloaded in RAM. The number to tweak is NUM_RAM_PRELOAD_SAMPLES (you increased it to 65536, thus experienced the mlockall problems). Try to lower it to 50k, 40k or even 32k. (although 32k is a bit low when streaming that much voices). Keep in mind NI Kontakt users reported being forced to use 150k samples of preload in some case in order to achieve stable operation. Of course this means you need a tons of RAM. Our numbers are actually quite good. > > And can't one simply allocate less memory and take a risk of drop outs > because we have less of the sample in memory? Yes this is the NUM_RAM_PRELOAD_SAMPLES value. The smaller this value the bigger the risk of dropouts during high polyphony passages. But as you have seen even with 32k (GSt uses 32k samples too) we can achieve a polyphony of 100+ voices ( = 200 in GSt's termionology) quite reliably. The chopin demo as run with 4msec latency and did not show a single dropout. And I rendered it to disk while surfing the net with Mozilla while my box was swapping nicely :-) Or are there hints in the > gig file that are telling you what to do? I should try some smaller > libraries and see what happens. No the hints are not in the GIG file, each disk based samples uses his own settings (and GSt is still the best windows sampler in terms of streaming because of its releatively efficient engine due to the kernel based engine). From reading various forums, the GSt's competition (Halion,Kontakt etc) is not able to deliver the same numbers because using the Windows APIs is slower than using the iron directly so they must compensate the inefficiencies by using large sample preload sizes. But this means being able to load less samples in RAM. 64bit is still an illusion on Windows so the upper RAM limits are 1-1.5GB. see here: http://www.pcworld.com/news/article/0,aid,112749,pg,6,00.asp This is why with GSt you can preload more samples on the same box than using the other windows softsamplers (which are better in terms of VSTi integration, more flexible, more effects etc). So for those needing many sample libraries preloaded (for large orchestral stuff) GSt still have some advantages. PS: saw an interview with Hans Zimmer on the german ZDF TV channel. They did show his studio (but not the GSt farm :-) ), kinda cool guy. We must all work hard so that LS lands in his studio too, you know we all need to fuel our personal egos :-)) cheers, Benno http://www.linuxsampler.org ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-11-18 00:03:12
|
On Mon, 2003-11-17 at 03:40, be...@ga... wrote: > Scrive Mark Knecht <mar...@co...>: > > The SustainedKeysPool FULL message is due to > audiothread.cpp: line 40: > SustainedKeyPool = new RTELMemoryPool<sustained_key_t>(200); > you must replace 200 with MAX_AUDIO_VOICES. > There can be as much sustaned voices as there are voices. > Download the latest CVS where Christian made some fixes that avoid > crashes and apply the above change. > Then set MAX_AUDIO_VOICES/STREAMS to 256, recompile and try to > drive LS to 240-250 voices and look at the 'top' command how much > CPU LS consumes. I'm curious :-) > Sorry. This version does not work for me. It loads up but actls like it's not receiving MIDI events and produces no audio. - Mark |
|
From: Christian S. <chr...@ep...> - 2003-11-17 23:05:36
|
Es geschah am Montag, 17. November 2003 12:40 als be...@ga... schrieb: > Download the latest CVS where Christian made some fixes that avoid > crashes and apply the above change. There is still at least one nasty bug, I will have a look at it when I have the time for it again (next couple of days). > Anyway LS currently uses a method to stream crompressed .GIG files which > is a bit suboptimal. Basically no caching of the decompressed stream is > performed so the decompressing is performed all the time (in the > low priority disk thread). > Anyway I'm unsure if caching would buy us anything because those samples > are so large that you could only cache small parts and playing dynamic > pieces you trigger a large number of the samples contained in the GIG so I > guess caching would be only a big coding work with maybe gaining only a few > % in terms of absolute performance. It wouldn't be a good idea at all to cache it, and the decompression algorithm is already quite optimal at least in the aspect that it's pure C++. Low level optimization would make sense here, but that has to wait until the more important things are done. Keep in mind: how many compressed gigs are out there? Not many... CU Christian |
|
From: <be...@ga...> - 2003-11-18 16:37:09
|
Scrive Christian Schoenebeck <chr...@ep...>: > Es geschah am Montag, 17. November 2003 12:40 als be...@ga... schrieb: > > Download the latest CVS where Christian made some fixes that avoid > > crashes and apply the above change. > > There is still at least one nasty bug, I will have a look at it when I have > the time for it again (next couple of days). Yes, for example if I do the following: load the compressed piano GIG, press sustain and eat up all polyphony (64) until you get no free voice messages. Then let the voices decay till the samples end. Now start to hit keys again (with and without sustain pressed) and you will notice several streams will remain active even when no voices are played. At this point you get lots of "disktstream not ready in time" messages. Christian any idea what could cause this ? I'm a bit busy this week so I cannot perform extensive debugging sessions. Anyway the new ReleaseVoice() code looks fine (pVoiceSelf etc), good job Christian ! > > > Anyway LS currently uses a method to stream crompressed .GIG files which > > is a bit suboptimal. Basically no caching of the decompressed stream is > > performed so the decompressing is performed all the time (in the > > low priority disk thread). > > Anyway I'm unsure if caching would buy us anything because those samples > > are so large that you could only cache small parts and playing dynamic > > pieces you trigger a large number of the samples contained in the GIG so I > > guess caching would be only a big coding work with maybe gaining only a > few > > % in terms of absolute performance. > > It wouldn't be a good idea at all to cache it, and the decompression > algorithm > is already quite optimal at least in the aspect that it's pure C++. Low level > > optimization would make sense here, but that has to wait until the more > important things are done. Keep in mind: how many compressed gigs are out > there? Not many... I agree on all the above, this is why I already said that the current method we use is perfectly fine. Christian any idea why on Mark's box the current CVS does not work ? Mark can you elaborate ? cheers, Benno http://www.linuxsampler.org ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-11-18 19:01:00
|
On Tue, 2003-11-18 at 08:37, be...@ga... wrote: > > Christian any idea why on Mark's box the current CVS does not work ? > Mark can you elaborate ? Benno, I don't know what to tell you. I built the code. It seemed to build without any errors. It starts up looking completely normal. When the gig file is loaded and I see the line where you count voices and streams I then hook up my keyboard to LS using kaconnect exactly as I did before. It acts as if it's attached according to kaconnect. However I when I hit keys on the keyboard I do not get any response from LS. The voices and stream count remains at 0 and I get no audio. I did not save the previous version of LS. I built over the top of that, so I lost that executable for testing. How can I check out a certain date of LS to go back and make sure this is really a code issue and not a problem on my end? I do see MIDI event lights on the MidiSport 2x2 that is receiving from the keyboard, so I assume they are getting to LS.I have no reason to expect any big problems with the machine, however my dad was here this weekend and I was using some of my USB devices on his new PC for test purposes, so maybe there's something going on. I'll recheck for loose cables and the like. Don't over react. It's likely something silly that I did. (I do this sort of stuff more than occasionally!) ;-) BTW - I don't know who to lobby, but once again I'll cry out that Alsa's user interface for MIDI devices is not user friendly. The idea that we users should remember numbers instead of having tools like kaconnect tell me which piece of hardware we're using and which soft synth we're attaching to is just not nice and error prone. Why should LS be 128:0. ZynAddSubFx at 129:0. Why should these numbers change from day to day. This just doesn't work well at all when I'm using 4 MIDI ports and 3 soft synths. I think that when we introduce the power of LS to the PC and Mac worlds it would be wise to have a solution to this. - Mark > > > cheers, > Benno > http://www.linuxsampler.org > > > ------------------------------------------------- > This mail sent through http://www.gardena.net > > > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <chr...@ep...> - 2003-11-18 23:29:25
|
Es geschah am Dienstag, 18. November 2003 17:37 als be...@ga... schrieb: > Yes, > for example if I do the following: load the compressed piano GIG, > press sustain and eat up all polyphony (64) until you get no free voice > messages. > Then let the voices decay till the samples end. > Now start to hit keys again (with and without sustain pressed) and you > will notice several streams will remain active even when no voices are > played. > At this point you get lots of "disktstream not ready in time" messages. > > Christian any idea what could cause this ? It seems that those streams that weren't finished just in time remain waiting to be picked up by a voice. So the number of available streams gets smaller and smaller. Should be easy to fix it. > Christian any idea why on Mark's box the current CVS does not work ? Nope, I don't really think it has to do something with my changes. Mark, have you removed the sources and tried a clean new checkout? Perhaps you just messed up something accidently. If a clean checkout doesn't solve it, you can checkout the old version by: cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler -D 15-Nov-03 co linuxsampler (one line of course) CU Christian |
|
From: Mark K. <mar...@co...> - 2003-11-20 02:08:58
|
On Tue, 2003-11-18 at 15:28, Christian Schoenebeck wrote: > > Christian any idea why on Mark's box the current CVS does not work ? > > Nope, I don't really think it has to do something with my changes. Mark, have > you removed the sources and tried a clean new checkout? Perhaps you just > messed up something accidently. Apparently I did mess something up. As I said, I was using my USB devices over the weekend to test my dad's new machine, so I had unplugged by MidiSport. When I was done I plugged it back in, but apparently plugged it into a different USB port. For whatever reason, the device was 'recognized' as a USB device, and using usbview I could see all the config data inside of it, but for some reason it doesn't get linked to the usb-audio driver when plugged into that port. I eventually noticed that the usb-audio driver, while loaded, said it was unused, so I plugged the MidiSport into a different USB port and then the MidiSport linked itself to usb-audio and started working again. Why should this be? Why doesn't Linux treat this stuff the same? I do not see much difference in terms of segfaults from the previous rev. It still dies after one or two notes as it did before. (Get up to a high voice count, let the voices die away so it all goes back to zero, then play a few notes and it crashes.) Anyway, with the MIDI input working again I played a bit with the new code. I don't have much good to report really. It does work now, in the sense that I get audio, but my sense (just from playing) was that somehow the sample choices it's making from a multi-sample/note library are not right. I got some very strange effects playing hard and soft. To study this a bit I ran the Bardstown piano through the MIDI velocity tests I had done earlier. This was the MIDI file supplied by Warren Trachtman. What I found was that volume is not varied at all over the complete range of MIDI velocities, while there seemed to be only 3 samples chosen out of the 4 in the library. This would seem to be a bug to me, but possibly not... I do not know if you are even attempting to chose samples based on velocity, nor do I know if you are trying to control volume at all based on velocity, so I won't call these results a bug until you report back what I should be getting. I hope this data helps. |
|
From: Christian S. <chr...@ep...> - 2003-11-23 21:41:41
|
Es geschah am Donnerstag, 20. November 2003 03:08 als Mark Knecht schrieb: > I do not see much difference in terms of segfaults from the previous > rev. It still dies after one or two notes as it did before. (Get up to a > high voice count, let the voices die away so it all goes back to zero, > then play a few notes and it crashes.) Sorry for answering that late; been very busy. You might have noticed, that I've commited a couple of fixes in the last days. The segfault issue you described should also be fixed now. > Anyway, with the MIDI input working again I played a bit with the new > code. I don't have much good to report really. It does work now, in the > sense that I get audio, but my sense (just from playing) was that > somehow the sample choices it's making from a multi-sample/note library > are not right. I got some very strange effects playing hard and soft. Yeah, Benno already told me that. Maybe there's a problem in the resolution of the sample. > To study this a bit I ran the Bardstown piano through the MIDI velocity > tests I had done earlier. This was the MIDI file supplied by Warren > Trachtman. What I found was that volume is not varied at all over the > complete range of MIDI velocities, while there seemed to be only 3 > samples chosen out of the 4 in the library. This would seem to be a bug > to me, but possibly not... Ok, the latter might be a bug, I will check that. Regarding the velocity<->volume mapping this is not yet implemented, but I will add that next. CU Christian |
|
From: Mark K. <mar...@co...> - 2003-11-23 23:40:48
|
On Sun, 2003-11-23 at 13:40, Christian Schoenebeck wrote: > Es geschah am Donnerstag, 20. November 2003 03:08 als Mark Knecht schrieb: > > I do not see much difference in terms of segfaults from the previous > > rev. It still dies after one or two notes as it did before. (Get up to a > > high voice count, let the voices die away so it all goes back to zero, > > then play a few notes and it crashes.) > > Sorry for answering that late; been very busy. You might have noticed, that > I've commited a couple of fixes in the last days. The segfault issue you > described should also be fixed now. Seems to be. Please see the response I wrote to Benno's email earlier today. > > > Anyway, with the MIDI input working again I played a bit with the new > > code. I don't have much good to report really. It does work now, in the > > sense that I get audio, but my sense (just from playing) was that > > somehow the sample choices it's making from a multi-sample/note library > > are not right. I got some very strange effects playing hard and soft. > > Yeah, Benno already told me that. Maybe there's a problem in the resolution of > the sample. > > > To study this a bit I ran the Bardstown piano through the MIDI velocity > > tests I had done earlier. This was the MIDI file supplied by Warren > > Trachtman. What I found was that volume is not varied at all over the > > complete range of MIDI velocities, while there seemed to be only 3 > > samples chosen out of the 4 in the library. This would seem to be a bug > > to me, but possibly not... > > Ok, the latter might be a bug, I will check that. Regarding the > velocity<->volume mapping this is not yet implemented, but I will add that > next. > Great! |
|
From: Marek P. <ma...@na...> - 2003-11-24 01:44:23
|
> Ok, the latter might be a bug, I will check that. Regarding the > velocity<->volume mapping this is not yet implemented, but I will add that > next. I wondered what would be the best way to implement it... how do other samplers handle this issue? I believe that both volume mapping and crossfading should be implemented at the same time since they seem to correpsond to each other, consider following situations: layer1 is pp layer2 is mf layer3 is ff +--layer1--+--layer2--+--layer3--+ +>>volume>>|>>volume>>|>>volume>>+ only volume is used. +--layer1--+--layer2--+--layer3--+ +>>>>x-fade>>>>>|>>>>>x-fade>>>>>+ only x-fading is used, no volume changes +--layer1---+---layer2---+--layer3--+ +>vol>|>x-fade>|>vol>|>x-fade>|>vol>| both are used So it seems that it would be very useful to have the possibility to adjust the ranges of volumes/x-fades with respect to each other or to turn off volumes or xfades. I think that they depend on each other. Marek |
|
From: Mark K. <mar...@co...> - 2003-11-24 03:53:52
|
On Sun, 2003-11-23 at 19:46, Marek Peteraj wrote: > > Ok, the latter might be a bug, I will check that. Regarding the > > velocity<->volume mapping this is not yet implemented, but I will add that > > next. > > I wondered what would be the best way to implement it... how do other > samplers handle this issue? This, I think, is pretty key. If people are using a library under GSt, and bring that library to LS, then they have a right to expect that it will sound substantially the same, and I think that if it doesn't, they won't continue to use LS. - Mark |
|
From: Marek P. <ma...@na...> - 2003-11-24 12:58:23
|
On Mon, 2003-11-24 at 04:53, Mark Knecht wrote: > On Sun, 2003-11-23 at 19:46, Marek Peteraj wrote: > > > Ok, the latter might be a bug, I will check that. Regarding the > > > velocity<->volume mapping this is not yet implemented, but I will add that > > > next. > > > > I wondered what would be the best way to implement it... how do other > > samplers handle this issue? > > This, I think, is pretty key. If people are using a library under GSt, > and bring that library to LS, then they have a right to expect that it > will sound substantially the same, and I think that if it doesn't, they > won't continue to use LS. Ok but the goal of linuxsampler isn't to clone gigasampler, it's just to provide full gig support. :) If the proposal i mentioned is ok and goes beyond Gst, that's only a good thing(tm). Marek |
|
From: Mark K. <mar...@co...> - 2003-11-24 14:42:51
|
On Mon, 2003-11-24 at 07:01, Marek Peteraj wrote: > On Mon, 2003-11-24 at 04:53, Mark Knecht wrote: > > On Sun, 2003-11-23 at 19:46, Marek Peteraj wrote: > > > > Ok, the latter might be a bug, I will check that. Regarding the > > > > velocity<->volume mapping this is not yet implemented, but I will add that > > > > next. > > > > > > I wondered what would be the best way to implement it... how do other > > > samplers handle this issue? > > > > This, I think, is pretty key. If people are using a library under GSt, > > and bring that library to LS, then they have a right to expect that it > > will sound substantially the same, and I think that if it doesn't, they > > won't continue to use LS. > > Ok but the goal of linuxsampler isn't to clone gigasampler, it's just to > provide full gig support. :) > If the proposal i mentioned is ok and goes beyond Gst, that's only a > good thing(tm). > > Marek Right, not a clone. It doesn't have to look anything like GSt. It does have to *Sound* like GSt. If LS doesn't play gig files so that they sound substantially the same as GSt then $$$$$ of dollars of gig files are useless to people that use GSt today. People write music based on what it sounds like. If they are using GSt and try this tool, they expect it to do everything GSt does in the audio realm. They are naturally going to compare how the Garritan library sounds, or how their favorite piano sounds, etc. If they don't sound the same I predict 98% of the potential users will just go away. Don't underestimate the importance of this. Not only are we asking GSt users to get a completely new computer to run this program, but we are asking them to load it with an operating system 99% of them have never used, and then run this program and listen to the results. The results had better be *really* good or it will be quite a disappointment. - my 4 cents... Mark |
|
From: Marek P. <ma...@na...> - 2003-11-25 01:15:08
|
On Mon, 2003-11-24 at 15:42, Mark Knecht wrote: > On Mon, 2003-11-24 at 07:01, Marek Peteraj wrote: > > On Mon, 2003-11-24 at 04:53, Mark Knecht wrote: > > > On Sun, 2003-11-23 at 19:46, Marek Peteraj wrote: > > > > > Ok, the latter might be a bug, I will check that. Regarding the > > > > > velocity<->volume mapping this is not yet implemented, but I will add that > > > > > next. > > > > > > > > I wondered what would be the best way to implement it... how do other > > > > samplers handle this issue? > > > > > > This, I think, is pretty key. If people are using a library under GSt, > > > and bring that library to LS, then they have a right to expect that it > > > will sound substantially the same, and I think that if it doesn't, they > > > won't continue to use LS. > > > > Ok but the goal of linuxsampler isn't to clone gigasampler, it's just to > > provide full gig support. :) > > If the proposal i mentioned is ok and goes beyond Gst, that's only a > > good thing(tm). > > > > Marek > > Right, not a clone. It doesn't have to look anything like GSt. It does > have to *Sound* like GSt. What i was talking about was - it has to sound like Gst if you want it to sound like Gst. But it can sound like anything else, or custom. My point was - flexibility. What we're aiming at AFAIK is to provide 100% .gig support, not Gst support. We just want to take full advantage of the .gig format, anything beyond that could be considered as reverse-engineering Gst(or any other app) which is forbidden. what i was trying to propose was to make the velocity system as flexible as possible from the start, so that it would handle virtually any kind of situation, custom settings, or that it could be used in conjunction with virtually any sampler velocity emulation, not just Gst. > > If LS doesn't play gig files so that they sound substantially the same > as GSt then $$$$$ of dollars of gig files are useless to people that use > GSt today. You forgot the akai users, the exs24 users, halion users, kontakt users, nnxt(not sure about that name, the reason sampler), and roland users(old hw samplers s-7xx). :) Marek |
|
From: Mark K. <mar...@co...> - 2003-11-25 02:43:28
|
On Mon, 2003-11-24 at 19:17, Marek Peteraj wrote: > What i was talking about was - it has to sound like Gst if you want it > to sound like Gst. But it can sound like anything else, or custom. My > point was - flexibility. > > What we're aiming at AFAIK is to provide 100% .gig support, not Gst > support. We just want to take full advantage of the .gig format, > anything beyond that could be considered as reverse-engineering Gst(or > any other app) which is forbidden. > > what i was trying to propose was to make the velocity system as flexible > as possible from the start, so that it would handle virtually any kind > of situation, custom settings, or that it could be used in conjunction > with virtually any sampler velocity emulation, not just Gst. I have no problem with anything you wrote. > > > > > If LS doesn't play gig files so that they sound substantially the same > > as GSt then $$$$$ of dollars of gig files are useless to people that use > > GSt today. > > You forgot the akai users, the exs24 users, halion users, kontakt users, > nnxt(not sure about that name, the reason sampler), and roland users(old > hw samplers s-7xx). :) No, I didn't really. I just fundamentally don't want things to get overly complicated supporting all this stuff before GSt support works very well. 100% audio compatibility with GSt, then do whatever else you want as we grab lots of new users. - Mark |
|
From: Marek P. <ma...@na...> - 2003-11-26 00:33:29
|
On Tue, 2003-11-25 at 03:43, Mark Knecht wrote: > On Mon, 2003-11-24 at 19:17, Marek Peteraj wrote: > > What i was talking about was - it has to sound like Gst if you want it > > to sound like Gst. But it can sound like anything else, or custom. My > > point was - flexibility. > > > > What we're aiming at AFAIK is to provide 100% .gig support, not Gst > > support. We just want to take full advantage of the .gig format, > > anything beyond that could be considered as reverse-engineering Gst(or > > any other app) which is forbidden. > > > > what i was trying to propose was to make the velocity system as flexible > > as possible from the start, so that it would handle virtually any kind > > of situation, custom settings, or that it could be used in conjunction > > with virtually any sampler velocity emulation, not just Gst. > > I have no problem with anything you wrote. > > > > > > > > > If LS doesn't play gig files so that they sound substantially the same > > > as GSt then $$$$$ of dollars of gig files are useless to people that use > > > GSt today. > > > > You forgot the akai users, the exs24 users, halion users, kontakt users, > > nnxt(not sure about that name, the reason sampler), and roland users(old > > hw samplers s-7xx). :) > > No, I didn't really. I just fundamentally don't want things to get > overly complicated supporting all this stuff before GSt support works > very well. 100% audio compatibility with GSt, then do whatever else you > want as we grab lots of new users. You'd grab a lot more users with akai support. What i don't like is to prefer one format over another and compromising designs in favor of one format if a general solution can be found or at least worked out in a reasonable way. I see linuxsampler as a project that aims to provide all features that another sampler would provide and more, a project that is innovative and unique, comfortable and userfriendly, efficient. *That's* what's going to get us tons of users. A fully fledged sampler, not a simple gig playback engine with a simple gui although 100% comatible and faithfully playing any .gig. I don't want LS end up being called as a Gst clone just because its name is similar to Gst and that it provides 100% compatibility, even if only for the beginning. So what i'm suggesting in general is - if .gig offers a certain model or system, can we extend upon that? how far can we go? is the model limited? is an unlimited model possible? If yes, let's implement that instead of the limited gig one, becasue the unlimited one will provide the same functionality. Will it take longer to develop? Certainly. But in the end we'll all have something better. And the development process could speed up considerably later on if the current code allows to easily implement other models/systems just because it was designed to be as flexible as possible, not just limited to one format. Marek |
|
From: Josh G. <jg...@us...> - 2003-11-26 02:44:10
|
On Tue, 2003-11-25 at 18:36, Marek Peteraj wrote:
<cut>
> So what i'm suggesting in general is - if .gig offers a certain model or
> system, can we extend upon that? how far can we go? is the model
> limited? is an unlimited model possible?
> If yes, let's implement that instead of the limited gig one, becasue the
> unlimited one will provide the same functionality.
>
The GigaSampler format seems like its very specific in its parameters
and the ranges of those parameters aren't really that much compared to
other formats. SoundFont uses 16 bit integers to describe all parameters
and DLS uses 32 bit. Don't get me wrong, GigaSampler does seem to offer
some nice features but I also agree that basing a synth just on that
format is probably short sited and its also a proprietary format. I
don't really see any problem with starting a synth with that format, but
it may be good to start adding some generic functionality from the
beginning.
GigaSampler does have some nice features like the dimension abstraction,
velocity cross fading and disk streaming. Disk streaming could be done
with DLS2 or SoundFont as well, nothing preventing that. The dimension
abstraction can be represented linearly by a list of regions that
trigger on certain criteria (velocity level, MIDI note, etc). The
velocity abstraction can also be implemented in SoundFont and DLS2 using
modulators/connection blocks respectively (although its not quite as
clean). Of note is that SoundFont/DLS2 can also have overlapping regions
(I haven't seen a way to do that in GigaSampler, but it wouldn't
surprise me if I'm wrong).
Providing a generic interface to GigaSampler for interfacing other
instrument formats would be really nice. FluidSynth has something like
this in place right now, although the parameters are SoundFont oriented
(not really that big of a problem really). Perhaps using DLS2 parameters
would be even more powerful in describing different formats.
Borrowing from the FluidSynth voice creation API:
LinuxSampler provides a noteon callback which passes a LinuxSampler
"voice" instance, the MIDI channel, note number and velocity to the
handler (or alternatively store these as fields in the LinuxSampler
instance). The handler is then responsible for creating voices in the
manner it sees fit (most of the voice data could be "cached", for speed,
from a "program" change handler that gets called when the MIDI
bank/program changes).
The handler routine would do something like this (very sudo code):
int
noteon_handler (LinuxSampler *ls)
{
foreach custom_voice
{
voice = ls.new_voice (<voice template ID>);
voice.set_param (DST_LFO_FREQ, custom_voice_val);
voice.set_param (DST_FILTER_CUTOFF, custom_voice_val);
voice.set_modulator (CONN_SRC_PITCHWHEEL, CONN_SRC_NONE,
CONN_DST_FILTER_CUTOFF, CONN_TRN_CONCAVE,
2400);
voice.set_sample_read_func (custom_sample_stream_callback);
}
ls.commit ()
}
Anyways, much is missing from that, but I hope someone gets the idea. By
using DLS2 parameters to form the base set of synthesis modules and then
allowing additional modules to be added (perhaps have "voice templates"
that would allow one to define a default voice state which a voice gets
initialized to with new_voice(template_id). I'm sure there are probably
a lot of tricks that would need to be done in order to not allocate any
memory or lock anything, etc. A lot of this type of stuff could be done
when the MIDI program changes, since whatever custom format is being
synthesized might have some calculation overhead to convert to this
format. The addition of modulators (connection blocks in DLS terms)
would allow for modulating capabilities. I hope that meant something to
someone. Cheers.
Josh Green
P.S. If you have read this far, perhaps you might be interested in a new
format I'm creating called FlacPak for losslessly compressing many
instrument formats (including GigaSampler). The web site for it is at:
http://swami.sourceforge.net/flacpak.php
|
Thanks for helping keep SourceForge clean.
X