Ecere SDK/eC Forums • View topic - Ecere applications do not work with Windows 7 64-bit /NVIDIA

Ecere SDK/eC Forums

Ecere Developers Community

Ecere applications do not work with Windows 7 64-bit /NVIDIA

General help specific to the Windows platform.

Ecere applications do not work with Windows 7 64-bit /NVIDIA

Postby sacrebleu » Sun Jun 13, 2010 9:23 pm

My hunch is this has something to do with the Quad core..

See this video:


Consulting with Chris Robinson (OpenAL) ... he is convinced there is a display issue or a threading issue, not related directly to OpenAL.

Using OpenGL

System specifications:
Intel Core2 Quad CPU 2.40GHz
64-bit Windows 7 Ultimate


2x monitors

NVIDIA System Information report created on: 06/13/2010 22:25:55
System name: H3-PC

Processor: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2406 MHz)
Operating System: Windows 7 Ultimate, 64-bit
DirectX version: 11.0
GPU processor: GeForce GTX 260
Driver version: 190.38
Stream processors: 192
Core clock: 620 MHz
Shader clock: 1296 MHz
Memory clock: 1080 MHz (2160 MHz data rate)
Memory interface: 448-bit
Total available graphics memory: 4095 MB
Dedicated video memory: 896 MB
System video memory: 0 MB
Shared system memory: 3199 MB
Video BIOS version: 62.00.0E.00.03
IRQ: 16
Bus: PCI Express x16


nvCpl.cpl NVIDIA Control Panel Applet
nvCplUI.exe NVIDIA Control Panel
nvWSS.dll NVIDIA Workstation Server
nvViTvS.dll NVIDIA Video and TV Server
NVMCTRAY.DLL NVIDIA Media Center Library
nvDispS.dll NVIDIA Display Server
NVCPL.DLL NVIDIA Compatible Windows7 Display driver, Version 190.38
PhysX 09.09.0408 NVIDIA PhysX
nvGameS.dll NVIDIA 3D Settings Server
Posts: 27
Joined: Sun Jan 17, 2010 12:37 pm

Re: Ecere applications do not work with Windows 7 64-bit /NVIDIA

Postby sacrebleu » Mon Jun 14, 2010 11:42 am

<KittyCat> sacrebleu, hi
<sacrebleu> on another machine, I ran the same app and only the audio seems to be choppy, the video works
<KittyCat> can you try to add a trace to the threaded alure calls to see if they're the ones being blocked?
<sacrebleu> i'm not really sure how I would do that
<KittyCat> you can (f)printf before and after, and print out some kind of good resolution system time (something like timeGetTime in Windows)
<sacrebleu> before and after what?
<KittyCat> the alure calls
<KittyCat> you can also trace out the processed buffer count and state
<sacrebleu> the thing that initiates the stream or the thing that updates it?
<KittyCat> the thing that updates it
<sacrebleu> i can but the machine it works on isn't on the network yet
<sacrebleu> so there will be a slight delay
<sacrebleu> what do you mean by processed buffer coutn
<KittyCat> the value you get form AL_BUFFERS_PROCESSED
<sacrebleu> is there a way to retreive that
<KittyCat> hmm.. can you paste the code you use to update?
<sacrebleu> this does not include the proposed printfs (that one is on the non-networked machine)
<KittyCat> the printf that are already there you can uncomment
<sacrebleu> k
<sacrebleu> sec
<KittyCat> and this is from a bad play (where it drops out)?
<sacrebleu> well, one issue is that to capture the buffer i have to switch from the display to the console, which causes the sound to play ok
<sacrebleu> so, I've tried to capture that
<KittyCat> if you run from the command line, you can redirect stdout to a file using foo >somefile.txt
<sacrebleu> k sec
<KittyCat> what is Start Time measured in (seconds, microseconds)?
<sacrebleu> i have no idea, i think its seconds
<sacrebleu> the problem is that there is no documentation for the Time class
<sacrebleu> and the developer of the IDE has banned me from his IRC channel (which was completely filled with non-users and he himself hasn't been doing any support recently)
<sacrebleu> strange that no capture device was detected
<sacrebleu> could be a driver issue - i didn't install the Realtek drivers there yet
<KittyCat> looks like there's some newlines missing..
<sacrebleu> "DelayExpired()" starts the function
<sacrebleu> so each cycle
<KittyCat> how big of a buffer are you using, and what openal format?
<sacrebleu> bufferSize=19200;
<sacrebleu> usesBuffers=3;
<sacrebleu> threadDelay=0.01f;
<sacrebleu> not sure what you mean by format
<KittyCat> the AL_FORMAT_ enum you use
<KittyCat> is that buffer size in bytes?
<sacrebleu> i think it is the default setting since I do not call AL_FORMAT_ anywhere
<sacrebleu> (inside the ALUREStream object)
<sacrebleu> buffer size is in bytes
<sacrebleu> i think...
<KittyCat> oh, right. sorry, I'm not really used to the older alure api myself anymore
<KittyCat> yes, that would be the size in bytes, which would be rather small
<sacrebleu> ok..
<sacrebleu> what is a recommended size
<KittyCat> try to use 128*1024 bytes
<KittyCat> which should be about 32K sample frames for 16-bit stereo, which is good
<sacrebleu> do you think this is the issue?
<sacrebleu> why would this interfere with the display?
<KittyCat> it wouldn't interfere with the display, but I notice in the log that it continually shows all three buffers processed
<KittyCat> that would cause the stream to stall and stutter, though I don't know why it would cut out for seconds on end
<KittyCat> fwiw, the newer alure version available in git has a more automatic method for streaming, so you don't have to do all this unqueueing/buffering/requeueing yourself
<KittyCat> it also has a method to specify the buffer size using time instead of bytes (so if you specify 250000, each buffer will take approximately 250ms, or 0.25 seconds, to play
<KittyCat> it works better than specifying the byte size since alure will pick the sample format for you, and some formats will run out of bytes quicker than others
<KittyCat> (it retains compatibility with all existing stuff, so you don't need to worry about that; these new capabilities are optional features you can use)
<sacrebleu> can you build me a DLL?
<sacrebleu> also, you made us a special DLL For use with this IDE
<sacrebleu> i dunno what was special about that but please take that into consideration

show details 9:54 AM (2 hours ago)

<sacrebleu> can you build me a DLL?
<sacrebleu> also, you made us a special DLL For use with this IDE
<sacrebleu> i dunno what was special about that but please take that into consideration
<KittyCat> hmm, I can't remember what was special about it either,,
<sacrebleu> it may have just been a fix
<sacrebleu> so, will you build me a new dll?
<KittyCat> checking through the logs, it does seem it was a bug fix for rewinding or something.
<sacrebleu> i'm not sure if i need updated includes / libs or whatever
<sacrebleu> this is all mingw
<KittyCat> you will need updated libs and headers if you want to use the new features
<sacrebleu> possibly
<sacrebleu> without re-implementing this interface, will this improve performance?
<KittyCat> possibly, though maybe not in a noticeable way
<KittyCat> what support libs do you want enabled?
<sacrebleu> support libs?
<KittyCat> libsndfile, libvorbisfile, etc
<sacrebleu> anything i can redist in a commercial project
<sacrebleu> so everything but lameenc
<sacrebleu> er lame
<KittyCat> and do you want them to be required for loading?
<sacrebleu> yeah i use libsndfile / libvorb/ogg
<sacrebleu> i am using flacs
<KittyCat> okay, so sndfile, vorbisfile, and flac
<sacrebleu> yes.. i also use wav
<KittyCat> do you want them to be required, or can support for them be silently disabled if the DLLs aren't present at run-time?
<sacrebleu> thats ok
<sacrebleu> silent (optional)
<KittyCat> okay..
<sacrebleu> in which case
<sacrebleu> support any and all dlls

show details 10:37 AM (2 hours ago)

<KittyCat> okay, it supports libsndfile, libvorbisfile, and libflac, dynamically
<sacrebleu> great
<sacrebleu> where do I get the includes / lib
<KittyCat> I have the dll, header, import lib, and docs in a 1.1MB zip
<sacrebleu> great
<KittyCat> I don't think DCC will work, though..
<sacrebleu> can you put it online?
<sacrebleu> if its only 1.1MB and contains no exe
<sacrebleu> or you could 7z it
<sacrebleu> and email
* KittyCat has offered (1143521 bytes)
* DCC RECV connect attempt to KittyCat failed (err=Connection timed out).
<sacrebleu> i've done this before
<sacrebleu> you have to use a direct connection
<KittyCat> yeah, I think the router isn't set up properly here
<sacrebleu> what client do you use
<KittyCat> I'll try emailing it
<sacrebleu> k
<KittyCat> Konversation
* Notify: KittyCat is online (FreeNode).
<KittyCat> sent
<sacrebleu> rec'vd
<KittyCat> essentially, the way you would do streaming now, is you create the stream and specify 0 buffers (so it creates the stream and doesn't pre-fill any buffers)
<KittyCat> then you call the new alurePlaySourceStream function with the source ID, stream pointer, and an optional EOS callback
<KittyCat> and regularly call alureUpdate() after that
<sacrebleu> hmm
<sacrebleu> its complaining .. sec
<sacrebleu> which of these should I get rid of?
<sacrebleu> #include <al/al.h>
<sacrebleu> #include <al/alc.h>
<sacrebleu> #include <al/alu.h>
<sacrebleu> #include <al/alure.h>
<sacrebleu> #include <al/efx.h>
<sacrebleu> #include <al/EFX-util.h>
<sacrebleu> #include <al/efx-creative.h>
<KittyCat> EFX-util isn't for mingw, iirc
<KittyCat> the header should work, but the lib with the actual functions don't
<sacrebleu> see i had to modify the headers
<sacrebleu> to get them to work
<sacrebleu> hrm
<sacrebleu> i am guessing one of those isn't working
<KittyCat> what's the error?
<sacrebleu> well, the IDE gives the elusive error message:
<sacrebleu> src\audio\ error: Couldn't open debug\openal.sym
<sacrebleu> 1 error, no warning
<sacrebleu> what this actually means is "error in .h"
<sacrebleu> or that the .h is missing
<sacrebleu> it is indicating al.h, but it really could be any of the includes
<sacrebleu> i'm going to send you a zip of my old modified .hs
<KittyCat> which ones did you modify?
<sacrebleu> it's been about 6 months since i touched them
<KittyCat> alu.h shouldn't exist, actually..
<KittyCat> and with openal soft's headers, you won't need efx-creative.h
<sacrebleu> hey it built
<KittyCat> and it should be AL/ instead of al/ (though this shouldn't matter in Windows)
<sacrebleu> it is AL
<sacrebleu> yes it should be
<sacrebleu> oops
<sacrebleu> spoke too soon
<sacrebleu> didn't build
<KittyCat> same problem?
<sacrebleu> yes
<sacrebleu> al.h is the same so its not that one
<KittyCat> there's no way to get the actual error?
<sacrebleu> ok so if you look inside alure.h that i sent you
<sacrebleu> you can see that I commented out certain parts
<sacrebleu> ln 4-13
<sacrebleu> why is efx-creative not for mingw?
<KittyCat> it's not that it isn't for mingw, it's that it's from creative's SDK headers
<sacrebleu> because i implemented all that in
<sacrebleu> here's a paste of the change i made to alure.h to get it to compile
<KittyCat> you have really really old headers..
<sacrebleu> you just sent me that
<KittyCat> in this zip you sent me
<sacrebleu> so i got it to build. the buffer is bigger
<sacrebleu> but it still has the display issue and choppyness
<sacrebleu> i gotta test on the other machine

<sacrebleu> its inside the "Ecere SDK"
<sacrebleu> i mean, we're seeing different behavior on one machine verse another
<sacrebleu> all of this works under WinXP32
<sacrebleu> but not under Win 7 64
<sacrebleu> ok, so on the other machine
<sacrebleu> the chirp is very short
* rdb (~rdb@panda3d/developer/rdb) has joined #openal
* ChanServ gives voice to rdb
<sacrebleu> so you want me to set usesBuffers =0
* rdb has quit (Client Quit)
<KittyCat> if you're going to use alure's streaming methods, yeah
* rdb (~rdb@panda3d/developer/rdb) has joined #openal
* ChanServ gives voice to rdb
<sacrebleu> what can i cut out of the delayexpired()
<KittyCat> everything. you don't need to do anything asynchronously
<sacrebleu> but i have to detect the end of the stream
<KittyCat> alure handles refeeding the buffer and restarting it from underruns automatically with alureUpdate();
<sacrebleu> so..
<sacrebleu> let's start with Play()
<KittyCat> you can passa callback to alurePlaySourceStream, which will get called when the stream stops
<sacrebleu> usesBuffers=0
<KittyCat> take out the alSourceQueueBuffers and alSourcePlay calls, and do alureSourcePlayStream instead
<KittyCat> pass in the same, the stream pointer, and the buffer count alure should use internally (which can be the count you used to pass to alureCreateStream*), along with an optional callback
<sacrebleu> what is the "stream pointer"
<sacrebleu> oh perhaps "buf"
<KittyCat> the alureStream* variable
<sacrebleu> ah, stream then
<sacrebleu> what is the format of the callback, void something() ?
<KittyCat> void eos_callback(void *userdata, ALuint source);
<sacrebleu> what do I pass StopSource
<KittyCat> the source id, and AL_TRUE if you want the callback to still be called, or AL_FALSE if not
<sacrebleu> src\audio\ warning: not enough arguments for function alurePlaySourceStream (3 given, expected 6)
<sacrebleu> src\audio\ warning: incompatible expression &this.eos_callback (void (void * a, uint s) *); expected uint
<sacrebleu> void eos_callback(void *a,ALuint s) { OnComplete(); }
<KittyCat> you can't use a non-static member function
<sacrebleu> what is ALSizei,
<sacrebleu> PLAYSOURCESTREAM)(ALuint,alureStream*,ALsizei,ALsizei,void(*)(void*,ALuint),void*);
<KittyCat> you have to use a static member function, and pass a pointer to 'this' as the userdata
<sacrebleu> a static member function is...
<KittyCat> ALURE_API ALboolean ALURE_APIENTRY alurePlaySourceStream(ALuint source, alureStream *stream, ALsizei numBufs, ALsizei loopcount, void (*eos_callback)(void *userdata, ALuint source), void *userdata);
<sacrebleu> static void something( void *userdata, ALuint b )
<sacrebleu> ?
<KittyCat> that's how you'd do it in C++, at least
<KittyCat> then cast and call ((ClassType*)userdata)->OnComplete();
<sacrebleu> ok well
<sacrebleu> without support that function will be null
<sacrebleu> what is ALsizei,ALSizei params
<KittyCat> the first one is the number of buffers alure should use internally, and the second is the number of times to loop the stream
<sacrebleu> so, 0, # of loops
<sacrebleu> ?
<KittyCat> 3, # of loops
<sacrebleu> to play once, 0?
<KittyCat> you pass 0 to alureCreateStream*, and a proper value to alurePlaySourceStream
<KittyCat> right
<sacrebleu> ok so right now I'm doing:
<sacrebleu> stream=alureCreateStreamFromFile((ALchar *) fn,bufferSize,usesBuffers,buf);
<sacrebleu> do I still use this
<KittyCat> usesBuffers would be 0, there (and you don't need buf anymore; you can pass NULL)
<KittyCat> stream=alureCreateStreamFromFile((ALchar *) fn, bufferSize, 0, NULL);
<sacrebleu> no sound is played
<KittyCat> make sure to call alureUpdate() regularly
<sacrebleu> you wanted me to remove alSourcePlay?
<KittyCat> yeah
<KittyCat> and alSourceQueueBuffers
<KittyCat> use alurePlaySourceStream instead
<KittyCat> then make sure alureUpdate is called regularly (it will handle all playing streams, so you don't need each stream handler to call it)
<KittyCat> or you can use alureUpdateInterval once, which will make alure automatically call it at the specified interval (roughly) from that point on
<sacrebleu> no sound
<KittyCat> and alure errors?
<KittyCat> *any
<sacrebleu> none
<KittyCat> alurePlaySourceStream will return AL_FALSE if something was wrong
<sacrebleu> alureUpdate() is being called often
<KittyCat> can you paste the code?
<sacrebleu> i'll paste the ALUREStream object
<sacrebleu> the alureUpdate() is called elsewhere inside the manager object
<KittyCat> and you're positive it's being called?
<sacrebleu> yeah just checked that
<KittyCat> 'k

show details 11:33 AM (1 hour ago)

<sacrebleu> many of the display issues changed
<sacrebleu> is there a shutdown procedure?
<KittyCat> for alure? not really. it should shut itself down with the app
<sacrebleu> alureDestroyStream(stream, usesBuffers, buf);?
<sacrebleu> is being called
<sacrebleu> is there another way
<KittyCat> that would be (stream, 0, NULL)
<sacrebleu> then destroy the source?
<KittyCat> after the stream, yeah
<sacrebleu> do i need to stop it first
<KittyCat> it should automatically be stopped if the stream it was playing is destroyed
<sacrebleu> ok so
<sacrebleu> the display issues seem to be tied to streams stopping
<sacrebleu> if i let the stream play through, no display issues occur
<sacrebleu> if I destroy a stream, it gets stuck in the blinky, blinky world.
<KittyCat> is anything trying to use the stream or source after they're destroyed?
<sacrebleu> destructor:
<sacrebleu> ~ALUREStream()
<sacrebleu> {
<sacrebleu> alureDestroyStream(stream, 0, null);// usesBuffers, buf);
<sacrebleu> delete source;
<sacrebleu> //unusedBuffers+=usesBuffers;
<sacrebleu> delete name;
<sacrebleu> }
<KittyCat> don't see anything wrong with that
<sacrebleu> so
<sacrebleu> it starts with a call to AddStream
<sacrebleu> yeah so
<sacrebleu> whenever the stream is destroyed i see the undef behavior

show details 12:41 PM (0 minutes ago)

<sacrebleu> jerome swears its not him
<sacrebleu> he says its an audio issue
<KittyCat> if it's an audio issue, it would have to be a driver thing
<sacrebleu> i think it has something to do with the destruction of the stream
<sacrebleu> the sounds are fine
<sacrebleu> its just a streaming thing
<KittyCat> I'm too tired to really think anymore, unfortunately. gonna have to go get some sleep
<sacrebleu> keep me posted
<KittyCat> if I can think of anything, I'll let you know
<sacrebleu> kty
Posts: 27
Joined: Sun Jan 17, 2010 12:37 pm

Return to Windows

Who is online

Users browsing this forum: No registered users and 2 guests