-
Welcome to the Pipe Organ Forum! This is a part of the open community Magle International Music Forums focused on pipe organs (also known as "church organs"), organists, organ music and related topics.
This forum is intended to be a friendly place where technically advanced organists and beginners (or even non-organists) can feel comfortable having discussions and asking questions. We learn by reading and asking questions, and it is hoped that the beginners (or non-organists) will feel free to ask even the simplest questions, and that the more advanced organists will patiently answer these questions. On the other hand, we encourage complex, technical discussions of technique, music, organ-building, etc. The opinions and observations of a diverse group of people from around the world should prove to be interesting and stimulating to all of us.
As pipe organ discussions can sometimes become lively, it should be pointed out that this is an open forum. Statements made here are the opinion of the poster, and not necessarily that of the forum itself, its administrator, or its moderators.
In order to post a new topic - or reply to existing ones - you may join and become a member by clicking on Register New User. It's completely free and only requires a working email address (in order to confirm your registration - it will never be given away!). We strive to make this a friendly and informative forum for anyone interested in pipe organs and organ music.
(Note: If you wish to link to and promote your own website please read this thread first.)
Many kind regards
Frederik Magle
Administrator
Krummhorn
Co-Administrator
GO for Windows 32/64
- Thread starter Cybug
- Start date
Cybug
New member
Hi - Well that was fun. Loaded OK upto 30 stops (GO memeory 1065596K)failed on the 31st with the attack memory problem (GO memory 1073628K). Then removed the 31st and added the 32nd failed with "out of memory loading" (GO memory 1088252). Then removed the 30th so we now have Stops 1-29 and Stop 32 this failed with the attack memory problem (GO memory 1079104K). Then shut down - tea time.
Restarted and decided to get back to a previous working point stops 1-30. This failed with wave data memory (GO memory 1093592) the GO memory was greater than the earlier test i.e. 1st test 1065596K and the second 1093592K - don't know why. This began to look like any value for GO memory greater than around 1700000K would cause the loading to fail? So I removed stop 30 i.e. now stops 1-29 and this loaded OK (GO memory 1057200). I then removed stop 29 and added 30 - this loaded OK (GO memory 1056048).
This leads me to assume that there is nothing wrong with the stops themselves. Dare I say, it would appear that something could be being overwritten in the memory allocation which may explain why were getting random error reports?
Next I removed stop 29 and added stop 31 this loaded OK (GO memory 1066196K). This result seemed to support my theory that there is nothing wrong with the stops themselves and the GO memory is below the magic figure of approx. 1700000K.
I could on with this for ages but I think there is enough here to hopefully give some clue as to what is going on. Happy to help if more info/tests are required.
As a plus I have noticed that the sound is brilliant, I don't know whether it's me, but there seems to be a greater clarity. I normally use the ASIO drivers and not the Direct drivers so that could make a difference. Still I'm having fun with only half an organ
Chris
Restarted and decided to get back to a previous working point stops 1-30. This failed with wave data memory (GO memory 1093592) the GO memory was greater than the earlier test i.e. 1st test 1065596K and the second 1093592K - don't know why. This began to look like any value for GO memory greater than around 1700000K would cause the loading to fail? So I removed stop 30 i.e. now stops 1-29 and this loaded OK (GO memory 1057200). I then removed stop 29 and added 30 - this loaded OK (GO memory 1056048).
This leads me to assume that there is nothing wrong with the stops themselves. Dare I say, it would appear that something could be being overwritten in the memory allocation which may explain why were getting random error reports?
Next I removed stop 29 and added stop 31 this loaded OK (GO memory 1066196K). This result seemed to support my theory that there is nothing wrong with the stops themselves and the GO memory is below the magic figure of approx. 1700000K.
I could on with this for ages but I think there is enough here to hopefully give some clue as to what is going on. Happy to help if more info/tests are required.
As a plus I have noticed that the sound is brilliant, I don't know whether it's me, but there seems to be a greater clarity. I normally use the ASIO drivers and not the Direct drivers so that could make a difference. Still I'm having fun with only half an organ
Chris
Cybug
New member
Hi
Have had no problems loading stops 1-30 today and once loaded it appears to be quite stable. Setting and saving Generals seems fine as does the manual presets. Ah! - please note the error in my GO memory load failure figure - it should read approx. 1070000K and not 1700000K - Oops! and which may well turn out to be the 1Gb boundry. I cannot be more accurate with this figure as it of course depends on each stop size. I'm very impressed with the sound quality and look forward to future builds
Chris
Have had no problems loading stops 1-30 today and once loaded it appears to be quite stable. Setting and saving Generals seems fine as does the manual presets. Ah! - please note the error in my GO memory load failure figure - it should read approx. 1070000K and not 1700000K - Oops! and which may well turn out to be the 1Gb boundry. I cannot be more accurate with this figure as it of course depends on each stop size. I'm very impressed with the sound quality and look forward to future builds
Chris
e9925248
New member
If I understand correctly, uncompressed can use up to 1.7 GB and compressed up to 1 GB - which is quite stange.
The memory limit for nomal win32 applications is about 1.7 GB (2 GB reserved for the system, the program code + various DLL requires some additional space).
My 32 bit GO build is not marked as LARGEADDRESSAWARE, so the 2 GB limit should apply. The 64 bit GO build should not suffer from this limitation.
[MS offers a tool to modifiy this flag in GrandOrgue.exe (http://msdn.microsoft.com/en-us/library/203797te.aspx). The tool is also part of the free MS Virtual Studio (C++) Express editions.]
According to some documentation on the net, for 32 bit large address aware programs on 64 bit Windows the system only reserve less then 800 MB. For 64 bit GO, it should be possible to use all memory assigned by Windows.
I could image, that fragmentation is wasting memory (especially for the compressed cache):
GO allocates a memory block for the whole sample, then allocate the memory for the various sample parts, copy the sample data into the new memory block and then frees the first allocation. If lossless compression is enabled, more tempory memory blocks are allocated. The result could be unusable free gaps between the various memory blocks (depending on the quality of the MS malloc implementation).
An estimation of the in-use memory of GO is given via File / Properties. On the other hand, the windows task manager provides in the processes tab the memory assigned by the system to the GrandOrgue.exe process (You can enable additional columns, which includes the virtual memory size too).
To determine, if you suffer from fragmentation, you should compare both values [Please note, that you must restart GO to clean up any fragementation and that there is a basic overhead, which can be determined looking at the values while loading a very small organ].
The memory limit for nomal win32 applications is about 1.7 GB (2 GB reserved for the system, the program code + various DLL requires some additional space).
My 32 bit GO build is not marked as LARGEADDRESSAWARE, so the 2 GB limit should apply. The 64 bit GO build should not suffer from this limitation.
[MS offers a tool to modifiy this flag in GrandOrgue.exe (http://msdn.microsoft.com/en-us/library/203797te.aspx). The tool is also part of the free MS Virtual Studio (C++) Express editions.]
According to some documentation on the net, for 32 bit large address aware programs on 64 bit Windows the system only reserve less then 800 MB. For 64 bit GO, it should be possible to use all memory assigned by Windows.
I could image, that fragmentation is wasting memory (especially for the compressed cache):
GO allocates a memory block for the whole sample, then allocate the memory for the various sample parts, copy the sample data into the new memory block and then frees the first allocation. If lossless compression is enabled, more tempory memory blocks are allocated. The result could be unusable free gaps between the various memory blocks (depending on the quality of the MS malloc implementation).
An estimation of the in-use memory of GO is given via File / Properties. On the other hand, the windows task manager provides in the processes tab the memory assigned by the system to the GrandOrgue.exe process (You can enable additional columns, which includes the virtual memory size too).
To determine, if you suffer from fragmentation, you should compare both values [Please note, that you must restart GO to clean up any fragementation and that there is a basic overhead, which can be determined looking at the values while loading a very small organ].
Cybug
New member
Hi
The load figures I gave on the 11th for the GO memory usage, were taken from the 'Processes' Tab in the Task Manager as requested and any others from then unless you request otherwise.
Anyway I tried loading GO v2.0.1 with the same organ but with all 56 stops. This loaded successfully with the GO memory at 1,797,448K. I closed the organ and reloaded OK with the GO mem now at 1,798,040. I then closed GO restarted and loaded the organ again and GO mem was 1,794,108K. This was without doing anything different then previous days (lossless compression set).
So I now decided to try your latest x64 bit version with lossless compression! This loaded successfully with the GO mem now at 2,065,192K - hurrah!
I now loaded the latest GO3 32bit version on my Win7 x64 machine with 16Gb Ram. This failed as previously i.e. max 30 stops.
It would seem that there is something in the GO3 32bit build that is causing the problem.
The x64 build runs fine but I noticed that GO3 doesn't seem to take any notice of the Amplitude volume set in the ODF file at present but I expect this is already known.
As this is the first x64 GIO available, I think I'll stick with now but I'll keep the x32 bit versions loaded should you need any more info
Thanks
Chris
The load figures I gave on the 11th for the GO memory usage, were taken from the 'Processes' Tab in the Task Manager as requested and any others from then unless you request otherwise.
Anyway I tried loading GO v2.0.1 with the same organ but with all 56 stops. This loaded successfully with the GO memory at 1,797,448K. I closed the organ and reloaded OK with the GO mem now at 1,798,040. I then closed GO restarted and loaded the organ again and GO mem was 1,794,108K. This was without doing anything different then previous days (lossless compression set).
So I now decided to try your latest x64 bit version with lossless compression! This loaded successfully with the GO mem now at 2,065,192K - hurrah!
I now loaded the latest GO3 32bit version on my Win7 x64 machine with 16Gb Ram. This failed as previously i.e. max 30 stops.
It would seem that there is something in the GO3 32bit build that is causing the problem.
The x64 build runs fine but I noticed that GO3 doesn't seem to take any notice of the Amplitude volume set in the ODF file at present but I expect this is already known.
As this is the first x64 GIO available, I think I'll stick with now but I'll keep the x32 bit versions loaded should you need any more info
Thanks
Chris
e9925248
New member
The amplitude issue is known (and fixed in svn). Workaround: Loading the organ a second time from cache uses the correct amplitude.
I'm working on building future 32 bit version as large address aware.
The 1 GB limit is still quite strange - I don't understand this behaviour.
I'm working on building future 32 bit version as large address aware.
The 1 GB limit is still quite strange - I don't understand this behaviour.
e9925248
New member
I created a new 32 experimental build (http://e9925248.users.sourceforge.net/gowin/, this time only the executable to replace the executable shipped in 32 bit installer, md5sum 6566f09bbaee79273867ae94989e3d9f).
It is marked as large address aware and contains a port of the pool allocator to windows (besides fixing the amplitude bug).
The property dialog (File/Properties in GO) displays 3 values: Allocated memory, memory reused from the cache and the maximum pool size (the last one mostly depends on the computer, not the ODF).
I hope, that this will improve your situation. I would be interessed in the maximum "allocated memory" (and "maximum pool size") numbers in the compressed and uncompressed case.
It is marked as large address aware and contains a port of the pool allocator to windows (besides fixing the amplitude bug).
The property dialog (File/Properties in GO) displays 3 values: Allocated memory, memory reused from the cache and the maximum pool size (the last one mostly depends on the computer, not the ODF).
I hope, that this will improve your situation. I would be interessed in the maximum "allocated memory" (and "maximum pool size") numbers in the compressed and uncompressed case.
Cybug
New member
Hi - Thanks for the new build.
Only had time for a short test but the Full 56 stops load OK on WinXP x64 3Gb with GO using 2051560K. This was with Lossless Compression. Runs fine and the amplitude issue is fixed as you said
I did try Win7 x64 16Gb and had some issues. Loading with no Lossless Compression - almost at the end of the loading procedure (GO memory 3244680) a large number of errors were output >40 with :- PoolAlloc failed : 14700 2146304000 7fff0000 ffe4428c ffed0000. The following list of errors were similar with only the first and 4th numbers being different. Nevertheless it loaded and seemed fine apart from clicking noises but this could be drivers as I don't normally use Direct Sound.
Then loaded again with LossLess Compression set and loaded OK (GO Memory 1904460K) loaded OK but still clicking whilst playing even single notes.
I will try and give you the values tomorrow as I have no time today. Thanks again for your help.
Regards
Chris
Only had time for a short test but the Full 56 stops load OK on WinXP x64 3Gb with GO using 2051560K. This was with Lossless Compression. Runs fine and the amplitude issue is fixed as you said
I did try Win7 x64 16Gb and had some issues. Loading with no Lossless Compression - almost at the end of the loading procedure (GO memory 3244680) a large number of errors were output >40 with :- PoolAlloc failed : 14700 2146304000 7fff0000 ffe4428c ffed0000. The following list of errors were similar with only the first and 4th numbers being different. Nevertheless it loaded and seemed fine apart from clicking noises but this could be drivers as I don't normally use Direct Sound.
Then loaded again with LossLess Compression set and loaded OK (GO Memory 1904460K) loaded OK but still clicking whilst playing even single notes.
I will try and give you the values tomorrow as I have no time today. Thanks again for your help.
Regards
Chris
e9925248
New member
The pool alloc messages are no fatal error. The sample grow to big for the maximum memory pool size, so it falls back to malloc.
What are the memory sizes reported in the GO property dialog?
To the click sound:
There are two direct sound backends (with and without PA). Without PA will click, if threading is enabled and a large latency is specified.
What are the memory sizes reported in the GO property dialog?
To the click sound:
There are two direct sound backends (with and without PA). Without PA will click, if threading is enabled and a large latency is specified.
Cybug
New member
Hi - Here are the sizes as requested:-
XPx64 3Gb Memory Lossless Compression: Allocated Memory = 1960938. Cache = 0. Pool Size = 2047691.
Win7 x64 16Gb Uncompressed : Allocated Memory = 3125910. Cache = 0. Pool Size = 2047645. - This gives the Alloc errors as previously.
Win7 x64 16Gb Lossless Compression : Allocated Memory = 1828125. Cache = 0. Pool Size = 2047645.
Hope this helps - anymore info required just ask.
Cheers
Chris
XPx64 3Gb Memory Lossless Compression: Allocated Memory = 1960938. Cache = 0. Pool Size = 2047691.
Win7 x64 16Gb Uncompressed : Allocated Memory = 3125910. Cache = 0. Pool Size = 2047645. - This gives the Alloc errors as previously.
Win7 x64 16Gb Lossless Compression : Allocated Memory = 1828125. Cache = 0. Pool Size = 2047645.
Hope this helps - anymore info required just ask.
Cheers
Chris
Cybug
New member
Hi
I'm having problems with another organ installation while loading which runs fine in GO v2. This causes GO3 to crash and requires either stopping the process using task manager or a re-boot. This is using your recent 32bit build on Win7 x64 with 16Gb ram. Do you wish me to pass on any details or should I wait until the software is more mature and try again?
Thanks
Chris
I'm having problems with another organ installation while loading which runs fine in GO v2. This causes GO3 to crash and requires either stopping the process using task manager or a re-boot. This is using your recent 32bit build on Win7 x64 with 16Gb ram. Do you wish me to pass on any details or should I wait until the software is more mature and try again?
Thanks
Chris
Cybug
New member
Hi - Using your recent 32bit build on Win7 x64 with 16Gb ram I have an APPCRASH while loading a 2GB organ which runs fine on the same machine using GO v2. The crash report is as follows:- App Name: GrandOrgue, App Version: 0.3.0.3, App Timestamp: 4f1348ce, Fault Module Name: msvcrt.dll, Fault Module Version: 7.0.7600.16385, Fault Module Timestamp: 4a5bda6f, Exception Code: c0000005, Exception Offset: 0000abc7.
The Memory used from the Process Tab is 2177824K which is left after GO is closed and needs clearing manually. Hope this helps - any more info required just ask.
Chris
The Memory used from the Process Tab is 2177824K which is left after GO is closed and needs clearing manually. Hope this helps - any more info required just ask.
Chris
Diode
New member
Hi All,
I have been a satisfied user of Grandorgue 0.2 since it's release and I have been eagerly awaiting 0.3. As I have an old Pentium 4 with no SSE3 support I recently installed GrandOrgue_without_sse3_build763.exe. I am very impressed with how this build sounds in comparison to 0.2.
Burea extended loads fully into 3GB of RAM under XP Pro (32) with lossless compression set. After the samples have loaded GrandOrgue's log contains 31K of "PoolAlloc failed" exceptions on my system - but I agree that they are non-fatal (GO behaves just fine if they are ignored).
0.3 build 763 definitely sounds better than 0.2 on my system when using the same sample set and the same supporting software (ASIO4All, Jack 1.9.8, qjackctl 0.3.4.10, Freeverb 3, and Savihost 1.36), and there is no obvious latency. My soundcard is an old SB Live with KX drivers. Incidentally - for anyone else using an SB Live for GO I strongly recommend that you ditch Creative's original drivers and replace them with KX as these offer noticibly better intermodulation distortion performance.
Sincere congratulations and thanks to the GrandOrgue developers for your efforts in refining GrandOrgue this far.
Regards,
Diode
I have been a satisfied user of Grandorgue 0.2 since it's release and I have been eagerly awaiting 0.3. As I have an old Pentium 4 with no SSE3 support I recently installed GrandOrgue_without_sse3_build763.exe. I am very impressed with how this build sounds in comparison to 0.2.
Burea extended loads fully into 3GB of RAM under XP Pro (32) with lossless compression set. After the samples have loaded GrandOrgue's log contains 31K of "PoolAlloc failed" exceptions on my system - but I agree that they are non-fatal (GO behaves just fine if they are ignored).
0.3 build 763 definitely sounds better than 0.2 on my system when using the same sample set and the same supporting software (ASIO4All, Jack 1.9.8, qjackctl 0.3.4.10, Freeverb 3, and Savihost 1.36), and there is no obvious latency. My soundcard is an old SB Live with KX drivers. Incidentally - for anyone else using an SB Live for GO I strongly recommend that you ditch Creative's original drivers and replace them with KX as these offer noticibly better intermodulation distortion performance.
Sincere congratulations and thanks to the GrandOrgue developers for your efforts in refining GrandOrgue this far.
Regards,
Diode
e9925248
New member
I have published a new build:
https://sourceforge.net/projects/e9925248.u/files/GrandOrgue/
It includes a new interpolation method: polyphase. The old method is called linear.
Polyphase has higher CPU demand. Polyphase + lossless compression enabled is currently handled as if linear has been selected.
https://sourceforge.net/projects/e9925248.u/files/GrandOrgue/
It includes a new interpolation method: polyphase. The old method is called linear.
Polyphase has higher CPU demand. Polyphase + lossless compression enabled is currently handled as if linear has been selected.
Cybug
New member
Hi - Thanks for the new builds.
I have so far tried the 32bit version on Win7x64 and XPx64 with the same result.
I am unable to "OPEN" an organ that has not previously been loaded but I can "OPEN RECENT" organ OK.
When attempting to "OPEN" an organ in Win7x64, GO crashes with the following info:
APP Crash GrandOrgue.exe
App Version: 0.3.0.4
App Timestamp: 4f37c550
Fault Module Name: wxmsw28u_core_gcc_custom.dll
Fault Module Version: 2.8.12.0
Fault Module Timestamp: 4ed5558d
Exception Code: c00000fd
Exception offset: 000db7de
Having loaded an organ in the recent list with no lossless compression all seems OK.
The "Close" organ function does nothing but you can overload another "recent" organ without any obvious problems.
Attempting to "Open" an organ even after a successful "Recent" organ, GO still crashes as above.
As you probably know I don't get any fault output when GO crashes in XPx64 but conditions are identical so I assume the crash is the same as Win7x64.
I'll try the x64 versions as soon as I can.
Cheers
Chris
I have so far tried the 32bit version on Win7x64 and XPx64 with the same result.
I am unable to "OPEN" an organ that has not previously been loaded but I can "OPEN RECENT" organ OK.
When attempting to "OPEN" an organ in Win7x64, GO crashes with the following info:
APP Crash GrandOrgue.exe
App Version: 0.3.0.4
App Timestamp: 4f37c550
Fault Module Name: wxmsw28u_core_gcc_custom.dll
Fault Module Version: 2.8.12.0
Fault Module Timestamp: 4ed5558d
Exception Code: c00000fd
Exception offset: 000db7de
Having loaded an organ in the recent list with no lossless compression all seems OK.
The "Close" organ function does nothing but you can overload another "recent" organ without any obvious problems.
Attempting to "Open" an organ even after a successful "Recent" organ, GO still crashes as above.
As you probably know I don't get any fault output when GO crashes in XPx64 but conditions are identical so I assume the crash is the same as Win7x64.
I'll try the x64 versions as soon as I can.
Cheers
Chris
e9925248
New member
You can skip this test - please wait for my next build.
Cybug
New member
Hi - Absolutely no need to apologise, I'm just very grateful for the huge effort you guys are putting in and I'm very happy
to help as much as can
Thanks again for the new build.
So far I have tried the 32bit and the 64bit versions on Win7 x64 with slightly different results.
On the 64 bit version I can load all "Recent" organs OK with Linear and Polyphase settings.
The audio output differs somewhat with two settings but I haven't spent too much time using
either so far.
I have also tried a new organ version which is slightly larger in memory size than I have before. This loads
fine in the 64 bit version and un-compressed shows in GO Properties Allocated Sample Memory:-1377.906MB,
Memory Cache:0 and Max Memory Pool Size:2.184MB. The Task Manger shows GO allocated: 5,656.608 MB.
The compressed figures are 3475.555Mb, 0, 15.637Mb and Task Manger 3,656.460Mb. I do also get the odd PoolAlloc
reports but seems to run OK.
Moving onto the 32 bit version.
Loading "Recent" organs seems all fine but attempting to load the larger organ fails with an AppCrash.
This occurs with No-Compression and Compression set. The failure report is as follows:
App Version: 0.3.0.5
App Timestamp: 4f3a14da
Fault Module: msvcrt.dll
Fault Module Version: 7.0.7600.16385
Fault Mod Timestamp: 425bda6f
Exception Code: c0000005
Exception Offset: 00009b60
This looks similar to the problem we saw before - see report on 25th Jan.
The Memory Allocation as given in the Task Manager for GO is 2756.752Mb
Non-compressed and 2436.564 compressed after the crash.
Anyway even with polyphase the latency has only increased a little from around 24 to 34 but
as yet, I haven't had much time to play about - my better half is recovering from an operation,
so I'm chief cook and bottlewasher at the moment :-(
I only have 3Gb on my XP box so I'll try v0.3.0.5 probably tomorrow without the new larger
organ for now.
Regards
Chris