linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

[Linuxsampler-devel] streaming bug

[Vladimir S. <ha...@gm...>]

Hi All,

I've got the "streaming bug" happening here very often.
At first this made me very happy only i foud out later that it was
caused by a combination of my scripts that caused "LOAD ENGINE" to get
executed more than once.
We had issues there. Not everything was destroyed and recreated back properly.
I think i've fixed most of that now, just checked in.
So now i'm back at square one. Problem doesn't happen anymore :(
I'm pretty sure everybody else who had this problem (including myself
previously) had something else (other than LOAD ENGINE) causing it. So
there probably more bugs there somewhere.
Please give it a try and report results. I'll keep chasing it for the
next few days (i'm on vacation here) but if nothing shows up we'll
probably have to add some debugging or something. If anyone knows how
to reproduce this please let me know :)

-- 
Regards,
Vladimir

Re: [Linuxsampler-devel] profiling, etc.

[Christian S. <sch...@so...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Vladimir S. <ha...@gm...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Garett S. <shu...@co...>]

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
>  
>

[Linuxsampler-devel] non-x86

[Vladimir S. <ha...@gm...>]

Hi All,

Christian has just checked in a change that should fix building LS on
non-x86 platforms.
Recent optimization checkins broke that but now it should build on
other platforms again. X86 specific optimizaitons will be disabled.
We have not yet implemented optimizations for other platforms.
Profiling should work on all supported platforms though.

-- 
Regards,
Vladimir

PS: merry xmas!

Re: [Linuxsampler-devel] profiling, etc.

[Vladimir S. <ha...@gm...>]

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
>

Re: [Linuxsampler-devel] profiling, etc.

[Matt F. <fl...@Ma...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Garett S. <shu...@co...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Vladimir S. <ha...@gm...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Garett S. <shu...@co...>]

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
>  
>

Re: [Linuxsampler-devel] profiling, etc.

[Vladimir S. <ha...@gm...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Vladimir S. <ha...@gm...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Christian S. <sch...@so...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Vladimir S. <ha...@gm...>]

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

Re: [Linuxsampler-devel] profiling, etc.

[Garett S. <shu...@co...>]

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.
>
>  
>

[Linuxsampler-devel] profiling, etc.

[Vladimir S. <ha...@gm...>]

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

Re: [Linuxsampler-devel] [PATCH] filter bugfix

[Vladimir S. <ha...@gm...>]

actually we'll still hit the same issues . . . a few more changes are
needed to complete this fix in Voice.cpp. I'll take care of that.


On Sat, 18 Dec 2004 13:21:19 -0500, Vladimir Senkov <ha...@gm...> wrote:
> Thanks Andreas!
> 
> This is my fault.
> We were trying to do something clever for performance reasons and
> rearranged this entire struct a few times, at the end under time
> pressure we had to gave up on part of the optimization and rollback
> one change. and as part of that rollback i also put the struct to back
> what it was without paying attention to a1 and a2 :(
> I'll check this into cvs in a few minutes.
> 
> Regards,
> Vladimir.
> 
> 
> On Sat, 18 Dec 2004 15:03:49 +0100, Andreas Persson
> <and...@lk...> wrote:
> > Hello,
> >
> > I think I've found a bug in BiquadFilter::Apply4StepsSSE. Let's see what
> > you think...
> >
> > /Andreas
> >
> >
> >
> 


-- 
Regards,
Vladimir

Re: [Linuxsampler-devel] [PATCH] filter bugfix

[Vladimir S. <ha...@gm...>]

Thanks Andreas!

This is my fault.
We were trying to do something clever for performance reasons and
rearranged this entire struct a few times, at the end under time
pressure we had to gave up on part of the optimization and rollback
one change. and as part of that rollback i also put the struct to back
what it was without paying attention to a1 and a2 :(
I'll check this into cvs in a few minutes.

Regards,
Vladimir.


On Sat, 18 Dec 2004 15:03:49 +0100, Andreas Persson
<and...@lk...> wrote:
> Hello,
> 
> I think I've found a bug in BiquadFilter::Apply4StepsSSE. Let's see what
> you think...
> 
> /Andreas
> 
> 
>

[Linuxsampler-devel] [PATCH] filter bugfix

[Andreas P. <and...@lk...>]

Hello,

I think I've found a bug in BiquadFilter::Apply4StepsSSE. Let's see what 
you think...

/Andreas

Re: [Linuxsampler-devel] optimizations

[Vladimir S. <ha...@gm...>]

Hi Mark,

Thanks for the report.
Unfortunately i do not have gigapiano gig so i can't reproduce this
problem myself.
Hopefully someone else does.
Is it possible for you to collect some more information so that i or
someone else could try to fix it?
Did this gig ever work in the past? If so, could you remember where?
Where does it crash? Could you get a coredump or at least a backtrace from it?
Also, could you try the latest version?

The INSTALL file will be adjusted when we finally have a release, i
believe at that point "make -f Makefile.cvs" will no longer be
required.

Regards,
Vladimir.

> Hi,
>    I thought that maybe I should try compiling and running LS/QS again
> as it's been awhile. I don't like CVS much so I went to Rui's site and
> downloaded the newest versions of libgig, liblscp, linuxsampler and
> qsampler that he has there.
> 
>    I finally managed to get them built. That was a bit of a struggle.
> Maybe someone could add the make -f Makefile.cvs step to the INSTALL
> file?
> 
>    When I tried to run them the qsampler gui comes up fine but when I
> tried to load GigaPIano it took a couple of minutes, appeared to use
> up a lot of memory, and then crashed and had to be killed.
> 
>    This is FC2/PlanetCCRMA with the newest PlanetEdge kernel. The gigs
> were on my 1394 audio drive I use with Ardour all the time.
> 
>    I know this isn't the most recent version. This note just documents
> what I ran into.
> 
> - Mark
>

Re: [Linuxsampler-devel] optimizations

[Mark K. <mar...@gm...>]

On Sun, 12 Dec 2004 20:01:23 -0500, Vladimir Senkov <ha...@gm...> wrote:
> Hi Everybody,
> 
> It may seem like LS has been quiet for a little while . . .
> But a lot of stuff has been happening behind the scenes.
> Christian and I have been working on optimizations with the goal of
> making LS nothing short of state of the art when it comes to
> efficiency.
> 
> We focused on improving efficiency of real time calculations.
> The project consisted of two major developments:
> 1) Reducing the amount of work and conditionals per sample point
> depending on the state of the voice.
> 2) Developing MMX/SSE(1) implementation for most calculation intensive
> routines (as well as providing a framework for further implementations
> such as SSE2/3, altivec, etc.
> 
> To acomplish task number 1 without introducing branches into the "fast
> path" we've introduced a concept which we called "synthesis mode". An
> entire segment is processed in the same mode.
> Function to process the entire mode is generated using highly
> templated CPP code.
> Ideally (depending on your compiler and options) an entire segment
> will be processed without a single call with only one branch (loop).
> So there is a function for each "synthesis mode" and there is a
> function pointer that is set for a voice before the segment is
> processed.
> 
> To acomplish task number 2 we had to write a few X86 assembly routines
> and do a lot of benchmarking, testing, etc. For some modes we
> acomplished speeds several times faster than CPP implementation.
> Further optimization will be made in some areas.
> We hit a number of issues related to FPU/MMX state problems of Pentium
> and also lots of funny GCC related things. We really wanted to support
> pre-SSE2 processors though.
> 
> Christian is working hard right now on checking everything into the CVS.
> I'd like to point out that there is still some work to be done (as usual) like:
> 1) Some cleanup, putting #if ARCH_X86 in place, etc
> 2) Integrating benchmarking into LS. For now we have separate
> benchmarking suite that we've used but it's not very user friendly and
> up to date, so we are not releasing it at this time. Benchmarking will
> allow users to do wonderful things such as comparing hardware to pick
> best fit for LS, etc.
> 3) cubic interpolation for MMXSSE needs to be implemented at some point
> 4) lots of other things
> 
> There will be subsequent submits to the CVS in the near future so
> please stay tuned!
> 
> --
> Regards,
> Vladimir
> 

Hi,
   I thought that maybe I should try compiling and running LS/QS again
as it's been awhile. I don't like CVS much so I went to Rui's site and
downloaded the newest versions of libgig, liblscp, linuxsampler and
qsampler that he has there.

   I finally managed to get them built. That was a bit of a struggle.
Maybe someone could add the make -f Makefile.cvs step to the INSTALL
file?

   When I tried to run them the qsampler gui comes up fine but when I
tried to load GigaPIano it took a couple of minutes, appeared to use
up a lot of memory, and then crashed and had to be killed.

   This is FC2/PlanetCCRMA with the newest PlanetEdge kernel. The gigs
were on my 1394 audio drive I use with Ardour all the time.

   I know this isn't the most recent version. This note just documents
what I ran into.

- Mark

Re: [Linuxsampler-devel] optimizations

[Vladimir S. <ha...@gm...>]

Thanks for the report Andreas, It is nice to know that it works on your machine!

Benchmarking is going to be a bit easier to do once we merge the
benchmarking tool in.
There are a few things here and there that could still be optimized .
. . but we need to first get some milage, clean up all the bugs and
merge benchmarking into ls.

Warning cleanup is also on the TODO list somewhere.
Speaking of TODO list, i was thinking about maintaining it somewhere
other than in everybody's head :) My head is not very good lately when
it comes to remembering something, especially when it involves
remembering what has to be done :)
maybe bug tracking system?
website?
plain old TODO file in the CVS?
I'd vote for bug tracking system, maybe this could take it off the ground :)

Regards,
Vladimir.

Re: [Linuxsampler-devel] optimizations

[Andreas P. <and...@lk...>]

On 12/13/2004 02:01 AM, Vladimir Senkov wrote:
> Hi Everybody,
> 
> It may seem like LS has been quiet for a little while . . .
> But a lot of stuff has been happening behind the scenes.

Great work! I thought I'd just let you know that the new version is 
working fine here! I haven't done any benchmarking though.

Not that it really bothers me, but during build I got a lot of warnings 
like this:

../../common/RTMath.h:173: warning: use of memory input without lvalue 
in asm operand 1 is deprecated

I use gcc 3.3.2.

/Andreas

[Linuxsampler-devel] optimizations

[Vladimir S. <ha...@gm...>]

Hi Everybody,

It may seem like LS has been quiet for a little while . . .
But a lot of stuff has been happening behind the scenes.
Christian and I have been working on optimizations with the goal of
making LS nothing short of state of the art when it comes to
efficiency.

We focused on improving efficiency of real time calculations.
The project consisted of two major developments:
1) Reducing the amount of work and conditionals per sample point
depending on the state of the voice.
2) Developing MMX/SSE(1) implementation for most calculation intensive
routines (as well as providing a framework for further implementations
such as SSE2/3, altivec, etc.

To acomplish task number 1 without introducing branches into the "fast
path" we've introduced a concept which we called "synthesis mode". An
entire segment is processed in the same mode.
Function to process the entire mode is generated using highly
templated CPP code.
Ideally (depending on your compiler and options) an entire segment
will be processed without a single call with only one branch (loop).
So there is a function for each "synthesis mode" and there is a
function pointer that is set for a voice before the segment is
processed.

To acomplish task number 2 we had to write a few X86 assembly routines
and do a lot of benchmarking, testing, etc. For some modes we
acomplished speeds several times faster than CPP implementation.
Further optimization will be made in some areas.
We hit a number of issues related to FPU/MMX state problems of Pentium
and also lots of funny GCC related things. We really wanted to support
pre-SSE2 processors though.

Christian is working hard right now on checking everything into the CVS.
I'd like to point out that there is still some work to be done (as usual) like:
1) Some cleanup, putting #if ARCH_X86 in place, etc
2) Integrating benchmarking into LS. For now we have separate
benchmarking suite that we've used but it's not very user friendly and
up to date, so we are not releasing it at this time. Benchmarking will
allow users to do wonderful things such as comparing hardware to pick
best fit for LS, etc.
3) cubic interpolation for MMXSSE needs to be implemented at some point
4) lots of other things

There will be subsequent submits to the CVS in the near future so
please stay tuned!

-- 
Regards,
Vladimir

Re: [Linuxsampler-devel] cancel release on note on?

[Vladimir S. <ha...@gm...>]

Hi Mark,

> So I think I'm not getting the idea across very well. Let's take 

I think i did understood and i'm not disagreeing, but i'd like to
figure out a few things.

> The issue to see here is that the exact time the second note starts
> can, in this simple case, have a dramatic effect on what you hear. If
> I play the second note exactly at a time n*1/1000 seconds later, then
> the second note reinforces the first and you get a signal that's twice
> as loud. However, if I play the note at n*1/2000 seconds later, where
> n is odd, then the two notes exactly cancel and you get no sound! The
> first sine wave is going down at the very instant that the second is
> going up. (A 180 degree phase shift)

agree, but only if the sample is uniform like sin(x)
 
> The second example is something that cannot happen with a real piano
> string.

true.

>Whatever the resultant waveform clearly the string is still
> vibrating. There are not two separate sine waves of the same frequency
> on the same string. There is one resultant vibration.

that depends on what the definition of "IS" is :)))
We could say that 2sin(x) is really sin(x)+sin(x) (and are in the same
phase) can't we?

> the two notes would be 'in sync' or would be playing with a 0 degree
> phase shift. This means that the two sets of samples are being read
> and played back in sync.

for the case of simple sin(x) two playin in sync will then be sin(x) +
sin(x) = 2sin(x). So that's the same one with twice the amplitude.
Moreover, if the sample is just sin(x) then if the first note was hit
with attack level 10 and another with attack level 20 and we (for the
sake of simplicity) play 10sin(x) for the first and 20sin(x) for
second we could then just play 30sin(x) for the two of them.
 
> The way playing two notes is different from playing one note is that
> the second note is reading the starting samples while the first note
> is reading samples further on in the stream. 

If sample is sin(x) then it doesn't matter because they will be
reading the same data. However if it's different then it will be
really difficult to define "in sync".

>The idea is that we keep
> the two streams separated by a value equal to some multiple of their
> fundamental frequencies.  I can elaborate on this more if required.

i think i understand the idea, but let's consider a few more examples.
let's say a sample is something like a bell.
for simplicity, let's forget about the envelope.
you take a note . . . sampler plays "Bim....Bom"
Now, if we play it the second time, what would be in sync for the two?
Technically speaking, "Bim" in the beginning of the sample could have
a period that is quite different from "Bom". So we can't really say
that Bim could be "in sync" with Bom.
Bell is perhaps not a very good example but i think there are many others.

So for some samples it "merging" could work while for some others it could not.

-- 
Regards,
Vladimir