• 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
    smile.gif

    Frederik Magle
    Administrator

    Krummhorn
    Co-Administrator

GO for Windows 32/64

e9925248

New member
On the 64 bit version I can load all "Recent" organs OK with Linear and Polyphase settings.

Linear/polyphase is a runtime setting. You can switch it without reloading.

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.

Wasn't that a 32 bit version? 2 GB max Pool size seems to indicate a 32 bit version and -1.3 GB looks like a integer overflow (if that is true, it would 2.9 GB).

In that case, you should have got a pool alloc error.

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.

The computer has about 15GB RAM?
These numbers should not have resulted in a pool alloc error.

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.
GO got the captibility to select the loading format for each pipe/rank seperatly (I don't remembers, if it was already present in my last 0.3.0.3 build) and tries to continue without crashing, if it rans out of memory during loading. In your case, continuing failed.

The MS crash information in that form is quite useless. The crash reporting tool produces some files [you can reach them via technical information in the crash dialog], which carry more information.
 

Cybug

New member
Hi - Thanks for your reply.

I have now tried both x32 and x64 builds using XP64 with 3GB Ram. All Organs, obviously within the memory bounds,
load with no problems seen and sound very good.
Just as an aside, all my organ versions are 16bit single loop and I don't have a 32bit version of XP available to test.

Reference your email above - I will double check my findings today just in case I did confuse the results.

Thanks - Chris
 

Cybug

New member
Hi - just a quick answer - yes it's a typo - sorry
Will post the details of the repeated tests tomorrow.

Chris
 

Cybug

New member
Hi - 4 Test results on Win7 x64 16Gb Ram.

1) v3.0.5 No compression 32bit build AppCrash GO v0.3.0.5
Fault Module: msvcrt.dll
Module Version: 7.0.7600.16385
Exception Code: c0000005
Exception Offset: 00009b60
GO Process Memory in Task Manager 2,756,788K

Re-boot Win7

2) v3.0.5 compression 32bit build AppCrash GO v0.3.0.5
Fault Module: msvcrt.dll
Module Version: 7.0.7600.16385
Exception Code: c0000005
Exception Offset: 0000aba6
GO Process Memory in Task Manager 2,405,448K

Re-boot Win7

3) v3.0.5 No compression 64bit version loads OK after:
Approx 50+ PoolAlloc failures
Organ Properties:
Allocated sample memory: 1377.907 MB
Mapped memory : 0
Maximum Memory Pool size: 6.763MB
GO Process Memory in Task Manager 5,652,064K

4) v3.0.5 Compression 64bit version loads OK after:
Approx 50+ PoolAlloc failures
Organ Properties:
Allocated sample memory: 3475.556MB
Mapped memory : 0
Maximum Memory Pool size: 6.762MB
GO Process Memory in Task Manager 3,637,372K

Hope this helps.

Chris
 

JLD

New member
Cybug & Diode,
Win32 build 831 are available in GrandOrgue SourceForge file (both version with and without sse3)
 

Cybug

New member
Hi JLD - Thanks for the builds (831).
I have run both builds on Win7 x64 16GB Ram using single loop samples @ 41Khz 16bit as

before. The organ used in tests 1-4 has failed to load in the 32bit builds to date
but runs fine in the last 64bit version.

1)With sse No compression AppCrash GO v0.3.0.5
Fault Module: GrandOrgue.exe
Module Version: 0.3.0.5
Exception Code: c0000005
Exception Offset: 0002a158
GO Process Memory in Task Manager 2,534,820K

2)With sse With compression AppCrash GO v0.3.0.5
Fault Module: GrandOrgue.exe
Module Version: 0.3.0.5
Exception Code: c0000005
Exception Offset: 0002a158
GO Process Memory in Task Manager 2,729,280K

3)No sse No-compression AppCrash GO v0.3.0.5
Crash report data as 1 an 2 above.
GO Process Memory in Task Manager 2,253,112K

4)No sse With compression AppCrash v0.3.0.5
Crash report data as 1 and 2 above
GO Process Memory in Task Manager 2,730,668K

5) Using organ which has loaded successfully in previous build v0.3.0.5
No sse No compression loaded with 100+ Pool Alloc failures - ran OK
GO Process Memory in Task Manager 2,440,616K
Allocated sample Memory 2351.795
Map Mem 0
Max Mem 2047.645

6) Same Organ as (5)
No sse With Compression loaded fine - no errors
GO Process Memory in Task Manager 2,440,616K
Allocated sample Memory 1371.094
Map Mem 0
Max Mem 2047.645

7)Another Organ loaded successfully on previuos builds
No sse With compression loaded fine no errors reported.
GO Process Memory in Task Manager 1,901,448K
Allocated sample Memory 1824.219
Map Mem 0
Max Mem 2047.645

8) Organ As above (7)
No sse No-compression AppCrash GO v0.3.0.5
Fault Module: GrandOrgue.exe
Module Version: 0.3.0.5
Exception Code: c0000005
Exception Offset: 0007246c
GO Process Memory in Task Manager 2,798,416K

I have stopped at this point as I've run out of time.

Is this excercise still of use to you?

Chris
 

Cybug

New member
Hi - Thanks for the new build. I have run both versions on Win7 x64 using single loop 44.1 and 16bit samples.
Both builds exhibit popping/spitting noises whilst in playing under no stress e.g. single stop.
The x64 build loads OK with just the alloc failures as previously.

The x32 build loads OK but with 2 error reports- "Can't read value of key
'HKCU\Software\Our Organ\GrandOrgue\AudioDevice\Device1\Channel1\Group1' (error 234: more data is available.)"
The x32 build:- the default value of 'Audio Output - Default channel groups - 48.000000dB' results in no audio output
and needs resetting to 000000 dB before the audio output works. This needs setting every reload and possibly related
to the error report above?

The best results, from an audio point of view, so far is the "GrandOrgue_861_EMU_0404_USB_COMP" build and gives
a latency of only 12ms but where this build sits in the overall developement life cycle I don't know.

Anyway, I hope this is useful and any more detail required, just ask

Regards Chris
 

e9925248

New member
The x32 build loads OK but with 2 error reports- "Can't read value of key
'HKCU\Software\Our Organ\GrandOrgue\AudioDevice\Device1\Channel1\Group1' (error 234: more data is available.)"
The x32 build:- the default value of 'Audio Output - Default channel groups - 48.000000dB' results in no audio output
and needs resetting to 000000 dB before the audio output works. This needs setting every reload and possibly related
to the error report above?

This looks like a problem related to reading the new settings (48 db and the read error) - I'll take a look at the problem.

I would expect, that with 48 dB gain, the sound output is malformed and a cut off of high sample values occures. I can't tell, if the result sounds like silence.

Hi - Thanks for the new build. I have run both versions on Win7 x64 using single loop 44.1 and 16bit samples.
Both builds exhibit popping/spitting noises whilst in playing under no stress e.g. single stop.
The x64 build loads OK with just the alloc failures as previously.

There is a new user configurable setting: Samples per buffer
I guess, that the old GO used 1024. What is your setting?

What are the concurrency settings?

Any change in the group tab?

The best results, from an audio point of view, so far is the "GrandOrgue_861_EMU_0404_USB_COMP" build and gives
a latency of only 12ms but where this build sits in the overall developement life cycle I don't know.

Sorry, for being not very verbose about the changes in the new version - I wanted the to test, if users can cope with the new audio configuration dialog.

To your question:
The GO projects offers the "stable" line [JLD managed to do a 64 bit too, so I hope, that he will start uploading them too].
Mine are the experimental line with even not yet commited features.

The sound engine in my build has seen bigger changes to support the new sound output features.

My top priority is to get it working for normal GO configurations again. You can try out the new sound output configuration possibilities, but be aware, that I currently only had time to test one variant under Linux.
 

Cybug

New member
Hi - Thanks for the info update.

There is a new user configurable setting: Samples per buffer
I guess, that the old GO used 1024. What is your setting?
Ah - hadn't appreciated that - oops! Changing the default value from 512 to 768+ solved the
noise problems on both builds.

What are the concurrency settings?
Default settings are 0 and 1. I have to admit I couldn't notice any change to the audio by altering
these values but then I'm not sure what to expect.

Any change in the group tab?
This TAB shows "Default Audio Group" in the selection window. This I assume is a new function.

My top priority is to get it working for normal GO configurations again. You can try out the new sound output configuration possibilities, but be aware, that I currently only had time to test one variant under Linux.
I'll have a suck - it - and - see session over the next few days but so far looks and behaves OK.

I wanted the to test, if users can cope with the new audio configuration dialog.
I can't see that being a problem as I imagine, like myself, once satisfied with the setup it will probably stay that
way for some time:)

Thanks

Chris
 

e9925248

New member
Ah - hadn't appreciated that - oops! Changing the default value from 512 to 768+ solved the noise problems on both builds.
I think, that I'll change the default to 1024, as it will cause a more stable sound output for most users.

So the sound problem is solved - any other regressions?

What are the concurrency settings?

Default settings are 0 and 1. I have to admit I couldn't notice any change to the audio by altering
these values but then I'm not sure what to expect.

Increasing these values will allow GO to make use of more than one processor core. I would start with a release concurrency equal to your core count and much higher concurrency.

I'll change the defaults too.

Any change in the group tab?

This TAB shows "Default Audio Group" in the selection window. This I assume is a new function.

Yes. It's the first part of the multi channel work.
 

e9925248

New member
I uploaded a new version:
https://sourceforge.net/projects/e9925248.u/files/GrandOrgue/

It contains all official changes since my last release (eg. multi channel support for one sound interface, new locking implementation, memory pool bug fixing).
Other changes:
* multi sound interface support (the implementation has not changed since the last beta, but it could take advance from other improvements)
* thread handling: concurency number need not to be arbitrary high numbers any more - they should be about the same as the number of cores
 

Ghekorg7 (Ret)

Rear Admiral Appassionata (Ret)
Thanks for this !
Just got it. Tomorrow I'll test and post back. I'm anxious to see the pool allocation and concurency fixes !! :-D

By the way I'm building a personal set with 4 release samples types for each note/pipe and so far I'm about to a 4GB set. GO commit 909 loads 2.950MB more or less.
The sound is terrific !!!!.
Sound FX are on too. I'm workin' on draw stop FX and some other minor stuff.

We got a winner here dear e.....
 

Cybug

New member
Hi - Thanks for the test builds.
So far I have tried both builds on Win7 x64 with no success.
GOx64 runs (very slowly) and after loading an organ (1.8Gb) it never seems to complete the process as the CPU is now running at 99% and the system is locked up. Apart from aweful clicks and cracks nothing else happens.
GOx32 fails after loading the same organ with: "Can't read from inflate stream: incorrect data check" and the program hangs. Have to Terminate using "end process" function.

I tried the x64 build on Win XP64 with similar results.

As an aside, I have the same problems with build 956 both x64 versions on XP and Win7.

The last build that seemed to function correctly was the x64 version of the 23 March (which I am still using on both XP and Win7)

Note:- I have M-Audio Delta 24/96 Sound cards on both systems. Only single loop samples and organ file around 2GB.

Any more info required just ask.

Thanks

Chris
 

e9925248

New member
So far I have tried both builds on Win7 x64 with no success.
GOx64 runs (very slowly) and after loading an organ (1.8Gb) it never seems to complete the process as the CPU is now running at 99% and the system is locked up. Apart from aweful clicks and cracks nothing else happens.
GOx32 fails after loading the same organ with: "Can't read from inflate stream: incorrect data check" and the program hangs. Have to Terminate using "end process" function.

I tried the x64 build on Win XP64 with similar results.

As an aside, I have the same problems with build 956 both x64 versions on XP and Win7.

My first suggestion after reading this, is, that you should clean the complete GO cache [delete/move all *.cache files from the GrandOrgueCache directory in the user settings directory - the settings dialog shows the full path too].
The cache contains some checksum to detect incompatible caches - but this does not catch all situations.

"Can't read from inflate stream: incorrect data check" suggest, that there is some kind of data corruption related to reading a compressed cache.

By the way:
The uncompressed cache should be retested too [NB: the compress cache setting only affect future created caches].
A bug has been fixed in r917, which allows GO to use memory mapping on Windows too. This could shorten the loading times from an uncompressed cache.
 
Top