# Import the necessary ocempgui parts. from ocempgui.object import ActionListener from ocempgui.widgets import * from ocempgui.widgets.Constants import * from pygame.locals import * import os.path import sys import pygame.mixer, pygame.time #, pygame.key
# ALL GLOBAL VARIABLES ARE IN CAPS! Q_MIXER = pygame.mixer Q_TIME = pygame.time Q_Key = pygame.key pygame.init Q_MIXER.pre_init(23024) # DOES NOT WORK! Hi Ethan, Yes and no, but what you eventually mentioned is what I did say. The screen mode being set and also the program she wrote and the delay placed between the loading of the file and queuing it in, setting it into the object. Just look at the example Clare gave and I placed it below. If I am not mistaken, I did read about the get_busy is only good while the sound is playing. Which is what I meant. Also, I have the new stuff loaded and the SDL does have a better setup. I do not know if she has all that loaded or not. But the interesting thing about this is the mixer.init parameters work in a test file I have which has none of the other stuff loaded, just the pygame. But with all the other stuff installed and also imported, the init is ignored. The example of the key inputs I gave I commented them out and it made no difference. I changed the values inside the () and made no difference. But when playing the old test file which goes straight in without loading any other imports the init works and varies with each change of the parameters. Same files, same format, but only difference is the amount of new stuff imported..; I.E. mentioned above at beginning of this email. Bruce Claire's Post: ------------------------------------------------------ import pygame pygame.init() screen = pygame.display.set_mode((500,500)) sound = pygame.mixer.Sound("dog.wav") pygame.time.delay(1000) sound.play() while pygame.mixer.get_busy(): pass ------------------------------------------------------ ----- Original Message ----- From: "Ethan Glasser-Camp" <[EMAIL PROTECTED]> To: <pygame-users@seul.org> Sent: Thursday, October 11, 2007 8:34 PM Subject: Re: [pygame] pygame.init before pygame.mixer.init? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RR4CLB wrote: > Hi Clare, > > I still think it is the same problem as before. The get_busy is only busy > when the file is playing. You have delayed it to allow the file to Queue in > and that has fixed it. If your hard drive is slow that would cause it. Most > things on the screen will not become active until the screen is active and > that to is part of the issue. Whether threading is an issue, which allows > somethings to move on while other things are still stuck in the mud has its > problems... To the best of my knowledge, when pygame.mixer.Sound() returns a Sound object, this means the file has been read. No "queueing" happens here, though it might for pygame.mixer.music. > Besides loading the initial package, load all the other packages. I am > not sure, but I think some of the other packages have a better mixer in it. As far as I know, there is only one pygame.mixer. There is also pygame.mixer.music, but I don't think it's what Clare Richardson is looking for. > You may just have a timing issue between machines that is being caught on > an accumulation of issues. That may cause a problem in cross platform > compatibility, but the get_busy is only active while a file is playing. It > must be playing first for it to work. If not, you will just run through that > while statement as if nothing ever played. The reason why putting a delay in > has fixed the issue. You allowed the file to actually start playing so the > busy is busy! I think you might have misread Clare Richardson's post: Clare's Post: ------------------------------------------------------ import pygame pygame.init() screen = pygame.display.set_mode((500,500)) sound = pygame.mixer.Sound("dog.wav") pygame.time.delay(1000) sound.play() while pygame.mixer.get_busy(): pass ------------------------------------------------------ > I've been able to determine that pygame.mixer.get_busy() isn't > failing, simply by replacing "pass" with print "Hello". This suggests strongly that in all cases, the file is completely loaded into memory, and that pygame.mixer is correctly figuring out how long the sound should be playing, and even "playing", but that somehow the sound isn't going anywhere. I'm not an expert on pygame internals, especially on Windows, but the fact that it works "better" after calling pygame.display.set_mode() reminds me of some problems people used to have focusing on DirectX windows. Namely: the application doesn't get access to sound, graphics, etc. until it opens a window. However, my vague recollection was also that DirectX was not the default any more. To force a non-DirectX audio driver, you could try doing something like: import pygame, os os.environ['SDL_AUDIODRIVER'] = waveout' before doing any pygame*.init(). As you may have gathered, I have no idea if this will actually work. Ethan