Menu
▾
▴
linuxsampler-devel
|
From: Vladimir S. <ha...@gm...> - 2004-12-21 05:35:54
|
Hi All, I've checked in a few changes into cvs. Hopefully fixed a bug or two (skip was not correctly passed into synthesizeFragment()). Some other minor cleanups. Some profiling capabilities (enabled by --profile flag) to allow a performer to see how many voices "in theory" could LS synthesizer handle. It uses current instuments and voices to figure out how long fragment synthesis takes and calculates a numbe in "bogovoices" that is printed to the screen every second. For now the main purpose is to compare CPP with ASM implementation. Higher number is better. We'll try to perfect this and other measurements and once that is done someone will hopefully write a better document describing these features. Next we will try to fix the long outstanding streaming bug. hopefully this coming weekend if all is well. Please report any bugs, changes, etc. and i'll try to fix them asap. -- Regards, Vladimir |
|
From: Garett S. <shu...@co...> - 2004-12-21 07:24:27
|
Hello, I checked out the cvs a few minutes ago and am getting a compilation error (last few lines of build posted below. I have tried -march=athlon -mcpu=athlon as well as the default i686 ). I have a copy that I checked out on the 5th of December which builds and works pretty well (nice work!). I am running an athlon xp 1700 with the 2.4.27 kernel which has been patched with low latency and kernel preemption (is this similar to what others are running?). Also, I think there might be a bug with the amplitude for voices that are triggerd by release velocity. The gig patches that have release voices play these voices very loudly when I trigger them on my keyboard. -Garett g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -march=athlon -mcpu=athlon -ffast-math -fpermissive -g -O2 -MT Voice.lo -MD -MP -MF .deps/Voice.Tpo -c Voice.cpp >/dev/null 2>&1 mv -f .libs/Voice.lo Voice.lo if /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -march=athlon -mcpu=athlon -ffast-math -fpermissive -g -O2 -MT Synthesizer.lo -MD -MP -MF ".deps/Synthesizer.Tpo" \ -c -o Synthesizer.lo `test -f 'Synthesizer.cpp' || echo './'`Synthesizer.cpp; \ then mv -f ".deps/Synthesizer.Tpo" ".deps/Synthesizer.Plo"; \ else rm -f ".deps/Synthesizer.Tpo"; exit 1; \ fi rm -f .libs/Synthesizer.lo g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -march=athlon -mcpu=athlon -ffast-math -fpermissive -g -O2 -MT Synthesizer.lo -MD -MP -MF .deps/Synthesizer.Tpo -c Synthesizer.cpp -fPIC -DPIC ../common/Resampler.h: In static member function `static void LinuxSampler::gig::Synthesizer<IMPLEMENTATION, CHANNELS, USEFILTER, INTERPOLATE, DOLOOP, CONSTPITCH>::Synthesize(sample_t*, void*, float&, float*, float*, uint&, float*, float*, float*, LinuxSampler::gig::Filter&, LinuxSampler::gig::Filter&, LinuxSampler::biquad_param_t&, LinuxSampler::biquad_param_t&) [with implementation_t IMPLEMENTATION = ASM_X86_MMX_SSE, LinuxSampler::gig::channels_t CHANNELS = MONO, bool USEFILTER = false, bool INTERPOLATE = false, bool DOLOOP = false, bool CONSTPITCH = true]': Synthesizer.h:135: instantiated from `static void LinuxSampler::gig::Synthesizer<IMPLEMENTATION, CHANNELS, USEFILTER, INTERPOLATE, DOLOOP, CONSTPITCH>::Synthesize(VOICE_T&, void*, sample_t*, uint&) [with VOICE_T = LinuxSampler::gig::Voice, implementation_t IMPLEMENTATION = ASM_X86_MMX_SSE, LinuxSampler::gig::channels_t CHANNELS = MONO, bool USEFILTER = false, bool INTERPOLATE = false, bool DOLOOP = false, bool CONSTPITCH = true]' Synthesizer.h:109: instantiated from `static void LinuxSampler::gig::Synthesizer<IMPLEMENTATION, CHANNELS, USEFILTER, INTERPOLATE, DOLOOP, CONSTPITCH>::SynthesizeFragment(VOICE_T&, unsigned int, sample_t*, uint&, uint&, unsigned int, unsigned int, unsigned int, uint&, void*, float&, float&) [with VOICE_T = LinuxSampler::gig::Voice, implementation_t IMPLEMENTATION = ASM_X86_MMX_SSE, LinuxSampler::gig::channels_t CHANNELS = MONO, bool USEFILTER = false, bool INTERPOLATE = false, bool DOLOOP = false, bool CONSTPITCH = true]' Synthesizer.h:73: instantiated from `static void LinuxSampler::gig::Synthesizer<IMPLEMENTATION, CHANNELS, USEFILTER, INTERPOLATE, DOLOOP, CONSTPITCH>::SynthesizeFragment(VOICE_T&, unsigned int, sample_t*, unsigned int) [with VOICE_T = LinuxSampler::gig::Voice, implementation_t IMPLEMENTATION = ASM_X86_MMX_SSE, LinuxSampler::gig::channels_t CHANNELS = MONO, bool USEFILTER = false, bool INTERPOLATE = false, bool DOLOOP = false, bool CONSTPITCH = true]' Synthesizer.cpp:150: instantiated from here ../common/Resampler.h:69: can't find a register in class `GENERAL_REGS' while reloading `asm' make[4]: *** [Synthesizer.lo] Error 1 make[4]: Leaving directory `/root/src/system/linuxsampler/linuxsampler/src/engines/gig' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/src/system/linuxsampler/linuxsampler/src/engines' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/src/system/linuxsampler/linuxsampler/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/src/system/linuxsampler/linuxsampler' make: *** [all] Error 2 root@homebox:~/src/system/linuxsampler/linuxsampler# Vladimir Senkov wrote: >Hi All, > >I've checked in a few changes into cvs. >Hopefully fixed a bug or two (skip was not correctly passed into >synthesizeFragment()). >Some other minor cleanups. >Some profiling capabilities (enabled by --profile flag) to allow a >performer to see how many voices "in theory" could LS synthesizer >handle. It uses current instuments and voices to figure out how long >fragment synthesis takes and calculates a numbe in "bogovoices" that >is printed to the screen every second. For now the main purpose is to >compare CPP with ASM implementation. Higher number is better. >We'll try to perfect this and other measurements and once that is done >someone will hopefully write a better document describing these >features. > >Next we will try to fix the long outstanding streaming bug. hopefully >this coming weekend if all is well. > >Please report any bugs, changes, etc. and i'll try to fix them asap. > > > |
|
From: Vladimir S. <ha...@gm...> - 2004-12-21 13:33:46
|
Hi Garett, This is a bummer. GCC can't find enough registers for assembly code to use. We've had these problems on and off and had to guide it a bit in these areas. In general, building with -O2 seems to have a better chance then -O1 or -O0. But it looks like you already have -O2 there. Could you send output from gcc --version? Some gcc versions seem to be better than others when it comes to optimizations. Dec5th was before the "optimization check in" so my guess is the bug you've mentioned with release volume has already been fixed. I remember similar experience. And this build problem was likely not introduced with checkins from last night, but rather the optimization checkins that we did a week earlier. So, to summarize. I'd like to reproduce this problem and to do this i need to know the exact gcc version. What i'll have to do is go to asm code and specify registers by hand or maybe reduce register usage somewhat if it doesn't hurt performance too much. My guess is this should not be too difficult. We'll probably have this figured out tonight or tomorrow night. Regards, Vladimir. On Tue, 21 Dec 2004 00:24:36 -0700, Garett Shulman <shu...@co...> wrote: > Hello, I checked out the cvs a few minutes ago and am getting a > compilation error (last few lines of build posted below. I have tried > -march=athlon -mcpu=athlon as well as the default i686 ). I have a copy > that I checked out on the 5th of December which builds and works pretty > well (nice work!). I am running an athlon xp 1700 with the 2.4.27 kernel > which has been patched with low latency and kernel preemption (is this > similar to what others are running?). Also, I think there might be a bug > with the amplitude for voices that are triggerd by release velocity. The > gig patches that have release voices play these voices very loudly when > I trigger them on my keyboard. -Garett > > g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -march=athlon -mcpu=athlon > -ffast-math -fpermissive -g -O2 -MT Voice.lo -MD -MP -MF .deps/Voice.Tpo > -c Voice.cpp >/dev/null 2>&1 > mv -f .libs/Voice.lo Voice.lo > if /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. > -I../../.. -march=athlon -mcpu=athlon -ffast-math -fpermissive -g -O2 > -MT Synthesizer.lo -MD -MP -MF ".deps/Synthesizer.Tpo" \ > -c -o Synthesizer.lo `test -f 'Synthesizer.cpp' || echo > './'`Synthesizer.cpp; \ > then mv -f ".deps/Synthesizer.Tpo" ".deps/Synthesizer.Plo"; \ > else rm -f ".deps/Synthesizer.Tpo"; exit 1; \ > fi > rm -f .libs/Synthesizer.lo > g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -march=athlon -mcpu=athlon > -ffast-math -fpermissive -g -O2 -MT Synthesizer.lo -MD -MP -MF > .deps/Synthesizer.Tpo -c Synthesizer.cpp -fPIC -DPIC > ../common/Resampler.h: In static member function `static void > LinuxSampler::gig::Synthesizer<IMPLEMENTATION, CHANNELS, USEFILTER, > INTERPOLATE, DOLOOP, CONSTPITCH>::Synthesize(sample_t*, void*, float&, > float*, float*, uint&, float*, float*, float*, > LinuxSampler::gig::Filter&, > LinuxSampler::gig::Filter&, LinuxSampler::biquad_param_t&, > LinuxSampler::biquad_param_t&) [with implementation_t IMPLEMENTATION = > ASM_X86_MMX_SSE, LinuxSampler::gig::channels_t CHANNELS = MONO, bool > USEFILTER = false, bool INTERPOLATE = false, bool DOLOOP = false, bool > CONSTPITCH = true]': > Synthesizer.h:135: instantiated from `static void > LinuxSampler::gig::Synthesizer<IMPLEMENTATION, CHANNELS, USEFILTER, > INTERPOLATE, DOLOOP, CONSTPITCH>::Synthesize(VOICE_T&, void*, sample_t*, > uint&) [with VOICE_T = LinuxSampler::gig::Voice, implementation_t > IMPLEMENTATION = ASM_X86_MMX_SSE, LinuxSampler::gig::channels_t CHANNELS > = MONO, bool USEFILTER = false, bool INTERPOLATE = false, bool DOLOOP = > false, bool CONSTPITCH = true]' > Synthesizer.h:109: instantiated from `static void > LinuxSampler::gig::Synthesizer<IMPLEMENTATION, CHANNELS, USEFILTER, > INTERPOLATE, DOLOOP, CONSTPITCH>::SynthesizeFragment(VOICE_T&, unsigned > int, sample_t*, uint&, uint&, unsigned int, unsigned int, unsigned int, > uint&, void*, float&, float&) [with VOICE_T = LinuxSampler::gig::Voice, > implementation_t IMPLEMENTATION = ASM_X86_MMX_SSE, > LinuxSampler::gig::channels_t CHANNELS = MONO, bool USEFILTER = false, > bool INTERPOLATE = false, bool DOLOOP = false, bool CONSTPITCH = true]' > Synthesizer.h:73: instantiated from `static void > LinuxSampler::gig::Synthesizer<IMPLEMENTATION, CHANNELS, USEFILTER, > INTERPOLATE, DOLOOP, CONSTPITCH>::SynthesizeFragment(VOICE_T&, unsigned > int, sample_t*, unsigned int) [with VOICE_T = LinuxSampler::gig::Voice, > implementation_t IMPLEMENTATION = ASM_X86_MMX_SSE, > LinuxSampler::gig::channels_t CHANNELS = MONO, bool USEFILTER = false, > bool INTERPOLATE = false, bool DOLOOP = false, bool CONSTPITCH = true]' > Synthesizer.cpp:150: instantiated from here > ../common/Resampler.h:69: can't find a register in class `GENERAL_REGS' > while > reloading `asm' > make[4]: *** [Synthesizer.lo] Error 1 > make[4]: Leaving directory > `/root/src/system/linuxsampler/linuxsampler/src/engines/gig' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/root/src/system/linuxsampler/linuxsampler/src/engines' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/root/src/system/linuxsampler/linuxsampler/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/src/system/linuxsampler/linuxsampler' > make: *** [all] Error 2 > root@homebox:~/src/system/linuxsampler/linuxsampler# > > Vladimir Senkov wrote: > > >Hi All, > > > >I've checked in a few changes into cvs. > >Hopefully fixed a bug or two (skip was not correctly passed into > >synthesizeFragment()). > >Some other minor cleanups. > >Some profiling capabilities (enabled by --profile flag) to allow a > >performer to see how many voices "in theory" could LS synthesizer > >handle. It uses current instuments and voices to figure out how long > >fragment synthesis takes and calculates a numbe in "bogovoices" that > >is printed to the screen every second. For now the main purpose is to > >compare CPP with ASM implementation. Higher number is better. > >We'll try to perfect this and other measurements and once that is done > >someone will hopefully write a better document describing these > >features. > > > >Next we will try to fix the long outstanding streaming bug. hopefully > >this coming weekend if all is well. > > > >Please report any bugs, changes, etc. and i'll try to fix them asap. > > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > -- Regards, Vladimir |
|
From: Christian S. <sch...@so...> - 2004-12-21 22:43:17
|
Es geschah am Dienstag 21 Dezember 2004 14:33 als Vladimir Senkov schrieb: > Hi Garett, > > This is a bummer. GCC can't find enough registers for assembly code to use. > We've had these problems on and off and had to guide it a bit in these > areas. In general, building with -O2 seems to have a better chance > then -O1 or -O0. > But it looks like you already have -O2 there. I was able to reproduce this with some GCC version coming with Redhat 9. Unfortunately the hard drive is currently detached on that box and I forgot to look for the GCC version. But I will look at it ASAP. Garett, in the meantime you can disable LS to be compiled with MMX SSE optimization. Even without those it's faster than with previous versions. Do the following: * comment out all SynthesizeFragment_modeX() methods in src/engines/gig/Synthesizer.cpp from mode 32 to the end, thus all which use the ASM_X86_MMX_SSE typedef in their method body * comment out all respective cases from 32 to the end in GetSynthesisFunction() (same file) * and finally place a simple 'return' or something at the beginning of method Features::detect(), so it won't detect MMX / SSE on your box CU Christian |
|
From: Garett S. <shu...@co...> - 2004-12-22 02:33:47
|
Hello Christian, I will try your suggestion this evening. Also, I noticed that I replied to Vladimir this morning instead of the list. The version of gcc that I am using is 3.2.3 (Debian). I can try upgrading this to whatever debian unstable is now at. I can also just leave the current version to test any fixes for this issue. Thanks. -Garett Christian Schoenebeck wrote: >Es geschah am Dienstag 21 Dezember 2004 14:33 als Vladimir Senkov schrieb: > > >>Hi Garett, >> >>This is a bummer. GCC can't find enough registers for assembly code to use. >>We've had these problems on and off and had to guide it a bit in these >>areas. In general, building with -O2 seems to have a better chance >>then -O1 or -O0. >>But it looks like you already have -O2 there. >> >> > >I was able to reproduce this with some GCC version coming with Redhat 9. >Unfortunately the hard drive is currently detached on that box and I forgot >to look for the GCC version. But I will look at it ASAP. > >Garett, in the meantime you can disable LS to be compiled with MMX SSE >optimization. Even without those it's faster than with previous versions. Do >the following: > > * comment out all SynthesizeFragment_modeX() methods in > src/engines/gig/Synthesizer.cpp from mode 32 to the end, thus all which use > the ASM_X86_MMX_SSE typedef in their method body > > * comment out all respective cases from 32 to the end in > GetSynthesisFunction() (same file) > > * and finally place a simple 'return' or something at the beginning of method > Features::detect(), so it won't detect MMX / SSE on your box > >CU >Christian > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://productguide.itmanagersjournal.com/ >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > |
|
From: Vladimir S. <ha...@gm...> - 2004-12-22 04:11:43
|
Hello Garett, Feel free to upgrade your gcc. I can easily reproduce this problem on my system using 3.2.3 gcc. and unfortunately many subsequent problems too :( I have a few versions of GCC on my test system and i don't mind to have as many as disk permits, i'm just putting then in different prefixes. So don't let this problem put your upgrades on hold. Some of the problems with "not enough registers" i can easily fix, but those fixes are most likely going to hurt performance (somewhat, hard to tell exactly by how much). Some of the problems with internal errors are not as easy to fix though. I'm stuck with some problem in the filter code, i think gcc is confused by the fact that we are trying to inline everything . . . this is a known gcc bug and it looks like it is not going to be fixed on 3.2.x because someone in gcc land deemed 3.2 not supported and advised folks to upgrade. Another issue is that old gcc won't inline some of the things that new gcc can. So performance of the code built with newer gcc will in most cases be better. Long story short i'm considering fixing the code up so that there is a macro ASM_SYNTHESIZER (or something like that). It could be driven by platrorm specific macros like ARCH_X86 (and other architectures where synthesizer will be implemented in assembly) OR gcc version being below 3.3 or something like that. I'd appreciate any comments, thoughts, etc on this from all interested parties :) Also, if you do upgrade gcc please let us know of any LS bugs you see (assuming the build will be OK after the upgrade ;) Regards, Vladimir. PS: i'm not very "debian aware" so if someone could enlighten me on what the gcc situation is in debian i'd appreciate it. i think debian packaging is very important and it is therefore important to understand the state they are in as far as gcc versions are concerned. On Mon, 20 Dec 2004 19:33:58 -0700, Garett Shulman <shu...@co...> wrote: > Hello Christian, I will try your suggestion this evening. Also, I > noticed that I replied to Vladimir this morning instead of the list. The > version of gcc that I am using is 3.2.3 (Debian). I can try upgrading > this to whatever debian unstable is now at. I can also just leave the > current version to test any fixes for this issue. Thanks. -Garett > > Christian Schoenebeck wrote: > > >Es geschah am Dienstag 21 Dezember 2004 14:33 als Vladimir Senkov schrieb: > > > > > >>Hi Garett, > >> > >>This is a bummer. GCC can't find enough registers for assembly code to use. > >>We've had these problems on and off and had to guide it a bit in these > >>areas. In general, building with -O2 seems to have a better chance > >>then -O1 or -O0. > >>But it looks like you already have -O2 there. > >> > >> > > > >I was able to reproduce this with some GCC version coming with Redhat 9. > >Unfortunately the hard drive is currently detached on that box and I forgot > >to look for the GCC version. But I will look at it ASAP. > > > >Garett, in the meantime you can disable LS to be compiled with MMX SSE > >optimization. Even without those it's faster than with previous versions. Do > >the following: > > > > * comment out all SynthesizeFragment_modeX() methods in > > src/engines/gig/Synthesizer.cpp from mode 32 to the end, thus all which use > > the ASM_X86_MMX_SSE typedef in their method body > > > > * comment out all respective cases from 32 to the end in > > GetSynthesisFunction() (same file) > > > > * and finally place a simple 'return' or something at the beginning of method > > Features::detect(), so it won't detect MMX / SSE on your box > > > >CU > >Christian > > > > > >------------------------------------------------------- > >SF email is sponsored by - The IT Product Guide > >Read honest & candid reviews on hundreds of IT Products from real users. > >Discover which products truly live up to the hype. Start reading now. > >http://productguide.itmanagersjournal.com/ > >_______________________________________________ > >Linuxsampler-devel mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > -- Regards, Vladimir |
|
From: Garett S. <shu...@co...> - 2004-12-22 05:57:00
|
Hey, I updated gcc to 3.3.5, checked out the current linuxsampler cvs and built successfully. However, linuxsampler now drops voices after only a few have been triggered (~6 voices). I rebuild the copy of linuxsampler that I checked out on Dec 5th and I don't notice any voice dropping even using the sustain pedal and triggering >30 voices. Also, I still get very loud release triggered voices on all of the patches that have release triggered voices. On the piano patch I have that has release triggered voices if I hold down the sustain pedal a key release triggers the voice that a corosponding key press would trigger (although much lounder than a key press) instead of the key release voice. I suppose it could be my patches as I haven't used them in gigastudio. Although all of the patches behave the same. I could create some recordings of this if that would be helpful. Very nice work none-the-less, though. Using the Dec 5th checkout and a patch without release voices I can jam away! I think that the jamming experience is very similar to what I can achieve with fluidsynth except that I am using a larger patch and taking up less ram! Right on! -Garett |
|
From: Matt F. <fl...@Ma...> - 2004-12-22 13:06:12
|
Regarding Debain, come the new year I should have submitted the Debian package .... Essentially it has many platforms and a 'trickle' down in stability ... I believe that the latest packaged version of gcc is 4.0 ? http://packages.debian.org/cgi-bin/search_packages.pl?keywords=gcc-&searchon=names&subword=1&version=all&release=all If you want my general feel about Debian, then listen to this RAW song : http://www.computerrebooter.com.au/~flatmax/debian.2004.turnTheTable.Take1.ogg Matt On Tue, Dec 21, 2004 at 11:11:29PM -0500, Vladimir Senkov wrote: > Hello Garett, > > Feel free to upgrade your gcc. I can easily reproduce this problem on > my system using 3.2.3 gcc. and unfortunately many subsequent problems > too :( > I have a few versions of GCC on my test system and i don't mind to > have as many as disk permits, i'm just putting then in different > prefixes. > So don't let this problem put your upgrades on hold. > > Some of the problems with "not enough registers" i can easily fix, but > those fixes are most likely going to hurt performance (somewhat, hard > to tell exactly by how much). > Some of the problems with internal errors are not as easy to fix > though. I'm stuck with some problem in the filter code, i think gcc is > confused by the fact that we are trying to inline everything . . . > this is a known gcc bug and it looks like it is not going to be fixed > on 3.2.x because someone in gcc land deemed 3.2 not supported and > advised folks to upgrade. > > Another issue is that old gcc won't inline some of the things that new > gcc can. So performance of the code built with newer gcc will in most > cases be better. > > Long story short i'm considering fixing the code up so that there is a > macro ASM_SYNTHESIZER (or something like that). It could be driven by > platrorm specific macros like ARCH_X86 (and other architectures where > synthesizer will be implemented in assembly) OR gcc version being > below 3.3 or something like that. > I'd appreciate any comments, thoughts, etc on this from all interested > parties :) > > Also, if you do upgrade gcc please let us know of any LS bugs you see > (assuming the build will be OK after the upgrade ;) > > Regards, > Vladimir. > > PS: i'm not very "debian aware" so if someone could enlighten me on > what the gcc situation is in debian i'd appreciate it. i think debian > packaging is very important and it is therefore important to > understand the state they are in as far as gcc versions are concerned. > > On Mon, 20 Dec 2004 19:33:58 -0700, Garett Shulman > <shu...@co...> wrote: > > Hello Christian, I will try your suggestion this evening. Also, I > > noticed that I replied to Vladimir this morning instead of the list. The > > version of gcc that I am using is 3.2.3 (Debian). I can try upgrading > > this to whatever debian unstable is now at. I can also just leave the > > current version to test any fixes for this issue. Thanks. -Garett > > > > Christian Schoenebeck wrote: > > > > >Es geschah am Dienstag 21 Dezember 2004 14:33 als Vladimir Senkov schrieb: > > > > > > > > >>Hi Garett, > > >> > > >>This is a bummer. GCC can't find enough registers for assembly code to use. > > >>We've had these problems on and off and had to guide it a bit in these > > >>areas. In general, building with -O2 seems to have a better chance > > >>then -O1 or -O0. > > >>But it looks like you already have -O2 there. > > >> > > >> > > > > > >I was able to reproduce this with some GCC version coming with Redhat 9. > > >Unfortunately the hard drive is currently detached on that box and I forgot > > >to look for the GCC version. But I will look at it ASAP. > > > > > >Garett, in the meantime you can disable LS to be compiled with MMX SSE > > >optimization. Even without those it's faster than with previous versions. Do > > >the following: > > > > > > * comment out all SynthesizeFragment_modeX() methods in > > > src/engines/gig/Synthesizer.cpp from mode 32 to the end, thus all which use > > > the ASM_X86_MMX_SSE typedef in their method body > > > > > > * comment out all respective cases from 32 to the end in > > > GetSynthesisFunction() (same file) > > > > > > * and finally place a simple 'return' or something at the beginning of method > > > Features::detect(), so it won't detect MMX / SSE on your box > > > > > >CU > > >Christian > > > > > > > > >------------------------------------------------------- > > >SF email is sponsored by - The IT Product Guide > > >Read honest & candid reviews on hundreds of IT Products from real users. > > >Discover which products truly live up to the hype. Start reading now. > > >http://productguide.itmanagersjournal.com/ > > >_______________________________________________ > > >Linuxsampler-devel mailing list > > >Lin...@li... > > >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > -- > Regards, > Vladimir > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel -- http://www.flatmax.org MFFM Bit Stream : http://sourceforge.net/projects/mffmbitstream/ Other Projects : http://sourceforge.net/search/?type_of_search=soft&words=mffm |
|
From: Vladimir S. <ha...@gm...> - 2004-12-22 02:32:05
|
I've installed gcc 3.2.3 on my box and i can reproduce the problem. the problem could probably be fixed but i'm not sure how yet. If i take that code out i hit the next problem: Synthesizer.h:318: Internal compiler error in fixup_var_refs_1, at function.c: 1966 Please submit a full bug report, i don't know how many more of these are out there. so i'm not sure we can fix all of those. maybe we'll have to limit ourselfs to supporting gcc 3.3.x and 3.4.x? I'll try a few more things before i give up . . . On Tue, 21 Dec 2004 23:55:28 +0100, Christian Schoenebeck <sch...@so...> wrote: > Es geschah am Dienstag 21 Dezember 2004 14:33 als Vladimir Senkov schrieb: > > Hi Garett, > > > > This is a bummer. GCC can't find enough registers for assembly code to use. > > We've had these problems on and off and had to guide it a bit in these > > areas. In general, building with -O2 seems to have a better chance > > then -O1 or -O0. > > But it looks like you already have -O2 there. > > I was able to reproduce this with some GCC version coming with Redhat 9. > Unfortunately the hard drive is currently detached on that box and I forgot > to look for the GCC version. But I will look at it ASAP. > > Garett, in the meantime you can disable LS to be compiled with MMX SSE > optimization. Even without those it's faster than with previous versions. Do > the following: > > * comment out all SynthesizeFragment_modeX() methods in > src/engines/gig/Synthesizer.cpp from mode 32 to the end, thus all which use > the ASM_X86_MMX_SSE typedef in their method body > > * comment out all respective cases from 32 to the end in > GetSynthesisFunction() (same file) > > * and finally place a simple 'return' or something at the beginning of method > Features::detect(), so it won't detect MMX / SSE on your box > > CU > Christian > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > -- Regards, Vladimir |
|
From: Vladimir S. <ha...@gm...> - 2004-12-22 02:33:06
|
BTW, by dropping support i mean support for CPU specific assembly optimizations, gcc should still be able to build CPP version fine. On Tue, 21 Dec 2004 21:30:36 -0500, Vladimir Senkov <ha...@gm...> wrote: > I've installed gcc 3.2.3 on my box and i can reproduce the problem. > the problem could probably be fixed but i'm not sure how yet. > If i take that code out i hit the next problem: > Synthesizer.h:318: Internal compiler error in fixup_var_refs_1, at function.c: > 1966 > Please submit a full bug report, > > i don't know how many more of these are out there. > > so i'm not sure we can fix all of those. maybe we'll have to limit > ourselfs to supporting gcc 3.3.x and 3.4.x? > I'll try a few more things before i give up . . . > > > On Tue, 21 Dec 2004 23:55:28 +0100, Christian Schoenebeck > <sch...@so...> wrote: > > Es geschah am Dienstag 21 Dezember 2004 14:33 als Vladimir Senkov schrieb: > > > Hi Garett, > > > > > > This is a bummer. GCC can't find enough registers for assembly code to use. > > > We've had these problems on and off and had to guide it a bit in these > > > areas. In general, building with -O2 seems to have a better chance > > > then -O1 or -O0. > > > But it looks like you already have -O2 there. > > > > I was able to reproduce this with some GCC version coming with Redhat 9. > > Unfortunately the hard drive is currently detached on that box and I forgot > > to look for the GCC version. But I will look at it ASAP. > > > > Garett, in the meantime you can disable LS to be compiled with MMX SSE > > optimization. Even without those it's faster than with previous versions. Do > > the following: > > > > * comment out all SynthesizeFragment_modeX() methods in > > src/engines/gig/Synthesizer.cpp from mode 32 to the end, thus all which use > > the ASM_X86_MMX_SSE typedef in their method body > > > > * comment out all respective cases from 32 to the end in > > GetSynthesisFunction() (same file) > > > > * and finally place a simple 'return' or something at the beginning of method > > Features::detect(), so it won't detect MMX / SSE on your box > > > > CU > > Christian > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > -- > Regards, > Vladimir > -- Regards, Vladimir |
|
From: Vladimir S. <ha...@gm...> - 2004-12-23 02:32:29
|
Garett, I'm glad it built. Too bad there are still problems, but hopefully we'll get them resolved soon. Are there any free or demo instruments that you can reproduce the release bug with? It would be easier to track down this way. I have GS so i could try it there as well to make sure that it works the same way. Two quick questions for latest LS: When voices are dropped do you see any error messages printed out? Like something being not ready, etc? :) Does it behave the same with and without ASM optimization or is it specific to ASM optimization? Optimization is on by default (if hardware supports it) but it can be turned off by a cmd line option. Regards, Vladimir. On Mon, 20 Dec 2004 22:57:12 -0700, Garett Shulman <shu...@co...> wrote: > Hey, > I updated gcc to 3.3.5, checked out the current linuxsampler cvs and > built successfully. However, linuxsampler now drops voices after only a > few have been triggered (~6 voices). I rebuild the copy of linuxsampler > that I checked out on Dec 5th and I don't notice any voice dropping even > using the sustain pedal and triggering >30 voices. Also, I still get > very loud release triggered voices on all of the patches that have > release triggered voices. On the piano patch I have that has release > triggered voices if I hold down the sustain pedal a key release triggers > the voice that a corosponding key press would trigger (although much > lounder than a key press) instead of the key release voice. I suppose it > could be my patches as I haven't used them in gigastudio. Although all > of the patches behave the same. I could create some recordings of this > if that would be helpful. Very nice work none-the-less, though. Using > the Dec 5th checkout and a patch without release voices I can jam away! > I think that the jamming experience is very similar to what I can > achieve with fluidsynth except that I am using a larger patch and taking > up less ram! Right on! > -Garett > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Garett S. <shu...@co...> - 2004-12-27 17:50:25
|
Hello, I have been fooling around with ls this weekend. I rechecked out ls and rebuild it on Friday (not sure if there was any change in cvs or not). I have found it to perform pretty well over the weekend. I setup an alsaseq filter to set all noteoff events to have a velocity of 1 and was able to play one of my patches without any issue! I did not reset the sampler or the channel for two days and was able to periodically sit down and jam. I did not notice any voice dropping or errors. Very nice! (this was with asm optimizations) However, none of the other patches I tried performed quite this well. On all of the other patches I try I eventually (after a minute or so) see: No unused stream found (OrderID:32) - report if this happens, this is a bug! No unused stream found (OrderID:33) - report if this happens, this is a bug! No unused stream found (OrderID:34) - report if this happens, this is a bug! No unused stream found (OrderID:35) - report if this happens, this is a bug! No unused stream found (OrderID:38) - report if this happens, this is a bug! No unused stream found (OrderID:39) - report if this happens, this is a bug! No unused stream found (OrderID:46) - report if this happens, this is a bug! ... No unused stream found (OrderID:66) - report if this happens, this is a bug! No unused stream found (OrderID:67) - report if this happens, this is a bug! No unused stream found (OrderID:68) - report if this happens, this is a bug! 0x4046d1e0Disk stream not available in time! 0x4046d1e0Disk stream not available in time! No unused stream found (OrderID:69) - report if this happens, this is a bug! ... No unused stream found (OrderID:90) - report if this happens, this is a bug! 0x4046d1e0Disk stream not available in time! No unused stream found (OrderID:91) - report if this happens, this is a bug! 0x4046d1e0Disk stream not available in time! 0x4046d1e0Disk stream not available in time! No unused stream found (OrderID:98) - report if this happens, this is a bug! 0x4046d1e0Disk stream not available in time! After this starts happening the voices drop at the same time as the Disk stream not available in time errors. Also, if I remove the channel after this happens and add a channel with the patch the works well I see this behavior. I can then kill ls, restart ls and add a channel with the patch that works well and it behaves properly. I'm not sure what the difference between that patches that I am using is that would allow one of them to work and not the others. They are all large (.9 - 1.8 GB) piano patches. I may ask Josh how gig support in libinstpatch is comming to see if it might be possible to use that to zero in on the differences that are causing these errors. I tried to find a demo patch that might illustrate the noteoff velocity issue I am encountering, but can only seem to find demo recordings of patches. I'm pretty sure that if I could create a one note patch that had the same sample (maybe just a sine wave) for noteon and noteoff I could recreate the problem. Maybe if libinstpatch gig support is mature enough I can use that to create such a patch. Let me know if there is any more information I can provide to assist. -Garett Vladimir Senkov wrote: >Garett, > >I'm glad it built. Too bad there are still problems, but hopefully >we'll get them resolved soon. >Are there any free or demo instruments that you can reproduce the >release bug with? It would be easier to track down this way. I have GS >so i could try it there as well to make sure that it works the same >way. >Two quick questions for latest LS: >When voices are dropped do you see any error messages printed out? >Like something being not ready, etc? :) >Does it behave the same with and without ASM optimization or is it >specific to ASM optimization? Optimization is on by default (if >hardware supports it) but it can be turned off by a cmd line option. > >Regards, >Vladimir. > >On Mon, 20 Dec 2004 22:57:12 -0700, Garett Shulman ><shu...@co...> wrote: > > >>Hey, >>I updated gcc to 3.3.5, checked out the current linuxsampler cvs and >>built successfully. However, linuxsampler now drops voices after only a >>few have been triggered (~6 voices). I rebuild the copy of linuxsampler >>that I checked out on Dec 5th and I don't notice any voice dropping even >>using the sustain pedal and triggering >30 voices. Also, I still get >>very loud release triggered voices on all of the patches that have >>release triggered voices. On the piano patch I have that has release >>triggered voices if I hold down the sustain pedal a key release triggers >>the voice that a corosponding key press would trigger (although much >>lounder than a key press) instead of the key release voice. I suppose it >>could be my patches as I haven't used them in gigastudio. Although all >>of the patches behave the same. I could create some recordings of this >>if that would be helpful. Very nice work none-the-less, though. Using >>the Dec 5th checkout and a patch without release voices I can jam away! >>I think that the jamming experience is very similar to what I can >>achieve with fluidsynth except that I am using a larger patch and taking >>up less ram! Right on! >>-Garett >> >>------------------------------------------------------- >>SF email is sponsored by - The IT Product Guide >>Read honest & candid reviews on hundreds of IT Products from real users. >>Discover which products truly live up to the hype. Start reading now. >>http://productguide.itmanagersjournal.com/ >>_______________________________________________ >>Linuxsampler-devel mailing list >>Lin...@li... >>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >> >> >> > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://productguide.itmanagersjournal.com/ >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > |
|
From: Vladimir S. <ha...@gm...> - 2004-12-27 18:11:01
|
Garett, Thanks for the update! So the problem with voice drops at ~6 voices is gone? We've seen the streaming bug for quite some time now and this bug is what's blocking us from release. I have some "holiday time" this week so i'll try to debug this problem. I've seen it on and off with pretty much every gig i have. Some more often than others. If i make any progress i'll keep you posted. About the note off problem. I'm not sure if Christian is aware of it, maybe he already is, but if he isn't then having a "test gig" made sounds like a very good idea. This should be easier to fix than the streaming bug. Regards, Vladimir. On Mon, 27 Dec 2004 10:50:37 -0700, Garett Shulman <shu...@co...> wrote: > Hello, > I have been fooling around with ls this weekend. I rechecked out ls and > rebuild it on Friday (not sure if there was any change in cvs or not). I > have found it to perform pretty well over the weekend. I setup an > alsaseq filter to set all noteoff events to have a velocity of 1 and was > able to play one of my patches without any issue! I did not reset the > sampler or the channel for two days and was able to periodically sit > down and jam. I did not notice any voice dropping or errors. Very nice! > (this was with asm optimizations) However, none of the other patches I > tried performed quite this well. On all of the other patches I try I > eventually (after a minute or so) see: > No unused stream found (OrderID:32) - report if this happens, this is a bug! > No unused stream found (OrderID:33) - report if this happens, this is a bug! > No unused stream found (OrderID:34) - report if this happens, this is a bug! > No unused stream found (OrderID:35) - report if this happens, this is a bug! > No unused stream found (OrderID:38) - report if this happens, this is a bug! > No unused stream found (OrderID:39) - report if this happens, this is a bug! > No unused stream found (OrderID:46) - report if this happens, this is a bug! > ... > No unused stream found (OrderID:66) - report if this happens, this is a bug! > No unused stream found (OrderID:67) - report if this happens, this is a bug! > No unused stream found (OrderID:68) - report if this happens, this is a bug! > 0x4046d1e0Disk stream not available in time! > 0x4046d1e0Disk stream not available in time! > No unused stream found (OrderID:69) - report if this happens, this is a bug! > ... > No unused stream found (OrderID:90) - report if this happens, this is a bug! > 0x4046d1e0Disk stream not available in time! > No unused stream found (OrderID:91) - report if this happens, this is a bug! > 0x4046d1e0Disk stream not available in time! > 0x4046d1e0Disk stream not available in time! > No unused stream found (OrderID:98) - report if this happens, this is a bug! > 0x4046d1e0Disk stream not available in time! > > After this starts happening the voices drop at the same time as the Disk > stream not available in time errors. Also, if I remove the channel after > this happens and add a channel with the patch the works well I see this > behavior. I can then kill ls, restart ls and add a channel with the > patch that works well and it behaves properly. I'm not sure what the > difference between that patches that I am using is that would allow one > of them to work and not the others. They are all large (.9 - 1.8 GB) > piano patches. I may ask Josh how gig support in libinstpatch is comming > to see if it might be possible to use that to zero in on the differences > that are causing these errors. I tried to find a demo patch that might > illustrate the noteoff velocity issue I am encountering, but can only > seem to find demo recordings of patches. I'm pretty sure that if I could > create a one note patch that had the same sample (maybe just a sine > wave) for noteon and noteoff I could recreate the problem. Maybe if > libinstpatch gig support is mature enough I can use that to create such > a patch. Let me know if there is any more information I can provide to > assist. > -Garett |
|
From: Christian S. <sch...@so...> - 2004-12-27 21:22:50
|
Es geschah am Montag 27 Dezember 2004 18:50 als Garett Shulman schrieb: > piano patches. I may ask Josh how gig support in libinstpatch is comming > to see if it might be possible to use that to zero in on the differences > that are causing these errors. I tried to find a demo patch that might You could use gigdump (coming with libgig) which outputs a lot of informations about a gig file on the console. Not very convenient, I know, but the only way ATM to figure out differences, not sure about Josh's progress though. I'm currently aware of 3 bugs left, which postpone the final release: * the mentioned disk stream bug with error message "No unused stream found" * a bug in Voice.cpp which causes samples to be played back too long, leading to noise at the end of samples * and finally the release velocity bug If you encountered one that is not already on this list, please let us know! I will also work on fixing those ASAP. But I'm currently a bit busy with work. :/ CU Christian |
Thanks for helping keep SourceForge clean.
X