Re: [pygame] pygame.init before pygame.mixer.init?
I tested the cases Clare mentioned, and was able to get the same behavior as her (specifically that doing a pygame.init first, sound would never be heard until after a display was sucessfully created, while doing a pygame.mixer.init first, the sound worked in all cases). Also, if I replace pygame.init with pygame.display.init, same results (display before mixer + no window = no sound) Ethan seems to have got things pegged with his DirectX comments too... On 10/11/07, Ethan Glasser-Camp [EMAIL PROTECTED] wrote: 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. When adding the code Ethan suggested above before pygame.init(), the sound worked for me even if the display wasn't created. So it seems clear to me that Ethan hit the nail on the head - the directX audio backend sets things up in a way that audio can't be played until after a window is created. The docs for pygame.mixer.init allude to this: http://www.pygame.org/docs/ref/mixer.html#pygame.mixer.init It seems though, that as Clare discovered, the directX backend only has that problem if pygame.display.init() is called before pygame.mixer.init(). pygame.init must call SDL in a way that does the display before the mixer. ...Ultimately, it seems to me that if you are making a game, with a window, none of this will matter at all. if you are making something that plays sounds with no window, then either force waveout for windows like Ethan suggested, or call pygame.mixer.init and forget about pygame.init and others.
Re: [pygame] pygame.init before pygame.mixer.init?
directX audio backend sets things up in a way that audio can't be played until after a window is created. The docs for pygame.mixer.init allude to this: http://www.pygame.org/docs/ref/mixer.html#pygame.mixer.init *** Yes, that is what I read and was refering to when I tried explaining it. I did not go and test Clare's problem myself, just relied on what I had read. Also, my demo/key thing has all the screen stuff set up and that allows the init stuff to be ignored as you stated below. Including the SDL installation. So Clare probably will never use the example given, but it is is an interesting thing to note. Who knows, it may cause problems down the road in some special cases, to early to tell... Bruce I tested the cases Clare mentioned, and was able to get the same behavior as her (specifically that doing a pygame.init first, sound would never be heard until after a display was sucessfully created, while doing a pygame.mixer.init first, the sound worked in all cases). Also, if I replace pygame.init with pygame.display.init, same results (display before mixer + no window = no sound) Ethan seems to have got things pegged with his DirectX comments too... On 10/11/07, Ethan Glasser-Camp [EMAIL PROTECTED] wrote: 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. When adding the code Ethan suggested above before pygame.init(), the sound worked for me even if the display wasn't created. So it seems clear to me that Ethan hit the nail on the head - the directX audio backend sets things up in a way that audio can't be played until after a window is created. The docs for pygame.mixer.init allude to this: http://www.pygame.org/docs/ref/mixer.html#pygame.mixer.init It seems though, that as Clare discovered, the directX backend only has that problem if pygame.display.init() is called before pygame.mixer.init(). pygame.init must call SDL in a way that does the display before the mixer. ...Ultimately, it seems to me that if you are making a game, with a window, none of this will matter at all. if you are making something that plays sounds with no window, then either force waveout for windows like Ethan suggested, or call pygame.mixer.init and forget about pygame.init and others.
RE: [pygame] pygame.init before pygame.mixer.init?
I did a little more testing: OS: Windows XP Pygame: I installed v1.7.1 for Win32 and Python 2.5 (http://www.pygame.org/ftp/pygame-1.7.1release.win32-py2.5.exe) I've reproduced the problem on one other WinXP machine with the same Pygame release, but the problem doesn't occur on my WinXP machine at home (the sound plays just fine without pygame.mixer.init). I've been able to determine that pygame.mixer.get_busy() isn't failing, simply by replacing pass with print Hello. Calling pygame.mixer.pre_init() instead of pygame.mixer.init doesn't get play any sound. *But* sound will play without pygame.mixer.init if I call pygame.display.set_mode AND put a time delay between loading the sound and playing it: -- 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 -- A few questions this brings up: * Why does setting the display make a difference, and why does this fix the problem of having to call pygame.mixer.init first? * Why does it take too long to load the sound, such that it won't play if I call it immediately? And why does calling pygame.mixer.init first make this problem go away? -- Clare Richardson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clare Richardson Sent: Wednesday, October 10, 2007 2:55 PM To: pygame-users@seul.org Subject: [pygame] pygame.init before pygame.mixer.init? I writing a program to simply play one sound (see below for the code), and came across some interesting behavior. If I call pygame.init() before pygame.mixer.init(), I don't hear any sound playing. However if I call pygame.init *after* pygame.mixer.init (as below), the sound will play. Is this a known behavior? What's causing the problem? I understand that I don't need pygame.init to just play a sound, but I don't think it should matter if I call it. Thanks! Clare Richardson --- import pygame pygame.mixer.init() pygame.init() sound = pygame.mixer.Sound(bark.wav) sound.play() while pygame.mixer.get_busy(): pass pygame.mixer.quit()
Re: [pygame] pygame.init before pygame.mixer.init?
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... 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. 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! Bruce I did a little more testing: OS: Windows XP Pygame: I installed v1.7.1 for Win32 and Python 2.5 (http://www.pygame.org/ftp/pygame-1.7.1release.win32-py2.5.exe) I've reproduced the problem on one other WinXP machine with the same Pygame release, but the problem doesn't occur on my WinXP machine at home (the sound plays just fine without pygame.mixer.init). I've been able to determine that pygame.mixer.get_busy() isn't failing, simply by replacing pass with print Hello. Calling pygame.mixer.pre_init() instead of pygame.mixer.init doesn't get play any sound. *But* sound will play without pygame.mixer.init if I call pygame.display.set_mode AND put a time delay between loading the sound and playing it: -- 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 -- A few questions this brings up: * Why does setting the display make a difference, and why does this fix the problem of having to call pygame.mixer.init first? * Why does it take too long to load the sound, such that it won't play if I call it immediately? And why does calling pygame.mixer.init first make this problem go away? -- Clare Richardson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clare Richardson Sent: Wednesday, October 10, 2007 2:55 PM To: pygame-users@seul.org Subject: [pygame] pygame.init before pygame.mixer.init? I writing a program to simply play one sound (see below for the code), and came across some interesting behavior. If I call pygame.init() before pygame.mixer.init(), I don't hear any sound playing. However if I call pygame.init *after* pygame.mixer.init (as below), the sound will play. Is this a known behavior? What's causing the problem? I understand that I don't need pygame.init to just play a sound, but I don't think it should matter if I call it. Thanks! Clare Richardson --- import pygame pygame.mixer.init() pygame.init() sound = pygame.mixer.Sound(bark.wav) sound.play() while pygame.mixer.get_busy(): pass pygame.mixer.quit()
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: 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDsEuhRlgoLPrRPwRAgXcAKC4hKmhx4uqHl3np7UGGMhXVUcX7QCdH3Qj rH7E2DwjA30FDOVLsaPZrmk= =4xyY -END PGP SIGNATURE-
Re: [pygame] pygame.init before pygame.mixer.init?
# 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
Re: [pygame] pygame.init before pygame.mixer.init?
The simplest thing to do is: --- import pygame from pygame.locals import * pygame.init() sound = pygame.mixer.Sound(bark.wav) sound.play() while pygame.mixer.get_busy(): pass --- ...because pygame.locals is everything you'll need: the keys module, surfaces, sound, etc. This way you don't have to do one line of code for every submodule you want to import: import pygame.key import pygame.mixer import pygame.draw import pygame.image import pygame.font import pygame.mouse --is = to:--- from pygame.locals import * --- I recommend doing this. I've been programming many times and realized that I hadn't imported all the necessary modules. Opps. Especially for simplicity, use from pygame.locals import * Anyway, about your question: Your first line, pygame.mixer.init() imports pygame.mixer (you can't init a non-loaded module), and then inits it. Your next line, pygame.init() inits all of the imported modules and pygame. So, here's what your code is doing: pygame.mixer.init() #imports pygame.mixer and inits pygame.mixer pygame.init() #inits all imported modules and pygame. (This re-inits pygame.mixer) One way to check would be to change the first line: - pygame.mixer.init() -becomes-- import pygame.mixer which will still work, but would not init the module, and so would be more efficient. Ian
RE: [pygame] pygame.init before pygame.mixer.init?
I tried running your code and don't hear anything playing. I added back pygame.mixer.init() before pygame.init() in your code, and it played. -- Clare From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Mallett Sent: Wednesday, October 10, 2007 4:18 PM To: pygame-users@seul.org Subject: Re: [pygame] pygame.init before pygame.mixer.init? The simplest thing to do is: --- import pygame from pygame.locals import * pygame.init() sound = pygame.mixer.Sound(bark.wav) sound.play() while pygame.mixer.get_busy (): pass --- ...because pygame.locals is everything you'll need: the keys module, surfaces, sound, etc. This way you don't have to do one line of code for every submodule you want to import: import pygame.key import pygame.mixer import pygame.draw import pygame.image import pygame.font import pygame.mouse --is = to:--- from pygame.locals import * --- I recommend doing this. I've been programming many times and realized that I hadn't imported all the necessary modules. Opps. Especially for simplicity, use from pygame.locals import * Anyway, about your question: Your first line, pygame.mixer.init() imports pygame.mixer (you can't init a non-loaded module), and then inits it. Your next line, pygame.init() inits all of the imported modules and pygame. So, here's what your code is doing: pygame.mixer.init() #imports pygame.mixer and inits pygame.mixer pygame.init () #inits all imported modules and pygame. (This re-inits pygame.mixer) One way to check would be to change the first line: - pygame.mixer.init() -becomes-- import pygame.mixer which will still work, but would not init the module, and so would be more efficient. Ian
Re: [pygame] pygame.init before pygame.mixer.init?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clare Richardson wrote: Is this a known behavior? What's causing the problem? I understand that I don't need pygame.init to just play a sound, but I don't think it should matter if I call it. Hi, I just ran your code, and it played the sound even without pygame.mixer.init(). What OS, pygame version, etc. are you using? Ethan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDUg0hRlgoLPrRPwRAvJtAJ9BODUhAF8ia6jLRdUPOHP/OHiGygCdFhBS gpIdhhzRJIiDlHt7d8BfXrU= =F2JG -END PGP SIGNATURE-
Re: [pygame] pygame.init before pygame.mixer.init?
Hi Clare, I am curious about this. If you do the mixer.init after the pygame one, place this inside the parens and se if it works. Also, the get_busy can fail if the mode of the mixer is set wrong, and that may be what is going on. If the channel mode is wrong, the busy will never get set true. I think the pygame.init is erasing all modes for the mixer. So you would have to place the modes in since the pygame.init erased them. Try and see if that fixes it. I had a problem with the get_busy and discovered that might just be the issue. Insert this into the mixer.init after the pygame init and see if it works. pygame.mixer.init(21024) # (freq, size, stereo, buffersize) # 1=mono, 2=stereo and 1024 buf size, 2050 for 16 bit pygame.mixer.init(21024) # 2 for stereo and 1024 for Buf Size - Original Message - From: Clare Richardson To: pygame-users@seul.org Sent: Wednesday, October 10, 2007 5:27 PM Subject: RE: [pygame] pygame.init before pygame.mixer.init? I tried running your code and don't hear anything playing. I added back pygame.mixer.init() before pygame.init() in your code, and it played. -- Clare From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Mallett Sent: Wednesday, October 10, 2007 4:18 PM To: pygame-users@seul.org Subject: Re: [pygame] pygame.init before pygame.mixer.init? The simplest thing to do is: --- import pygame from pygame.locals import * pygame.init() sound = pygame.mixer.Sound(bark.wav) sound.play() while pygame.mixer.get_busy (): pass --- ...because pygame.locals is everything you'll need: the keys module, surfaces, sound, etc. This way you don't have to do one line of code for every submodule you want to import: import pygame.key import pygame.mixer import pygame.draw import pygame.image import pygame.font import pygame.mouse --is = to:--- from pygame.locals import * --- I recommend doing this. I've been programming many times and realized that I hadn't imported all the necessary modules. Opps. Especially for simplicity, use from pygame.locals import * Anyway, about your question: Your first line, pygame.mixer.init() imports pygame.mixer (you can't init a non-loaded module), and then inits it. Your next line, pygame.init() inits all of the imported modules and pygame. So, here's what your code is doing: pygame.mixer.init() #imports pygame.mixer and inits pygame.mixer pygame.init () #inits all imported modules and pygame. (This re-inits pygame.mixer) One way to check would be to change the first line: - pygame.mixer.init() -becomes-- import pygame.mixer which will still work, but would not init the module, and so would be more efficient. Ian No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.6/1061 - Release Date: 10/10/2007 8:43 AM
Re: [pygame] pygame.init before pygame.mixer.init?
Hi Clare, comments below On 10/10/07, Clare Richardson [EMAIL PROTECTED] wrote: I writing a program to simply play one sound (see below for the code), and came across some interesting behavior. If I call pygame.init() before pygame.mixer.init(), I don't hear any sound playing. However if I call pygame.init *after* pygame.mixer.init (as below), the sound will play. Is this a known behavior? What's causing the problem? I understand that I don't need pygame.init to just play a sound, but I don't think it should matter if I call it. The behavior you describe may very well be a bug, and is something that should probably be fixed - and if some SDL and/or pygame source programmer repro's it with your sample code, it probably will get fixed. However, I don't think calling pygame.mixer.init is ever really a good thing, and you probably shouldn't bother. There is another function, pygame.mixer.pre_init, which takes the same args as pygame.mixer.init, and is specifically designed to be called before pygame.init Basically if you are calling mixer.init without args... well I don't think there is any benefit to doing so, and so you might be happier if you don't If you are calling it with args, well try calling pygame.mixer.pre_init instead, just before your pygame.init call, cause it will make sure your mixer gets init once only, the right way for your given args you want to use.
