Re: [pygame] vista testing...
I don't think this has been confirmed as an SDL bug, yet - playmus didn't exhibit a problem, right? However, there's no known problem with the current default pygame.mixer settings either, right? (because aliens and playwave worked...) So it seems to me there should maybe be some documented errata for certain mixer init settings being scratchy, but it doesn't seem like there is anything to hold back 1.8 release On Thu, Mar 27, 2008 at 5:16 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > ok... > > So what do we do from here? > > I think this is only something we can document, and then try and get > fixed in SDL_mixer? I don't think we should wait on this for 1.8. > Instead make a really good bug report to the SDL_mixer people, and > help them fix it for a pygame 1.8.1 release. > > What do you think Lenard? > > > > > > > On Thu, Mar 27, 2008 at 3:08 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > > Thanks. This confirms what I have found. > > > > Lenard > > > > > > > > > > Bo Jangeborg wrote: > > > Aliens sounds good and used the following > > > Video driver: windib > > > Audio driver: dsound > > > > > > Lenard Lindstrom skrev: > > >> To answer Brian, the default audio driver is dsound. SDL exports > > >> function SDL_AudioDriverName. Maybe Pygame should wrap it. I found > > >> and compiled a C space aliens game* that uses SDL, SDL_image and > > >> SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, > > >> channels 2, chunk size 3072. It is available on my Pygame page. Copy > > >> the contents of the zip file into prebuilt\lib and run. It writes to > > >> stderr.txt which drivers it uses. I suggest replacing the default > > >> data\music.wav with something else as it is a noisy recording. > > >> > > >> > > > > >
Re: [pygame] vista testing...
ok... So what do we do from here? I think this is only something we can document, and then try and get fixed in SDL_mixer? I don't think we should wait on this for 1.8. Instead make a really good bug report to the SDL_mixer people, and help them fix it for a pygame 1.8.1 release. What do you think Lenard? On Thu, Mar 27, 2008 at 3:08 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Thanks. This confirms what I have found. > > Lenard > > > > > Bo Jangeborg wrote: > > Aliens sounds good and used the following > > Video driver: windib > > Audio driver: dsound > > > > Lenard Lindstrom skrev: > >> To answer Brian, the default audio driver is dsound. SDL exports > >> function SDL_AudioDriverName. Maybe Pygame should wrap it. I found > >> and compiled a C space aliens game* that uses SDL, SDL_image and > >> SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, > >> channels 2, chunk size 3072. It is available on my Pygame page. Copy > >> the contents of the zip file into prebuilt\lib and run. It writes to > >> stderr.txt which drivers it uses. I suggest replacing the default > >> data\music.wav with something else as it is a noisy recording. > >> > >> > >
Re: [pygame] vista testing...
smpeg. MAD is GPL, and SDL_mixer and pygame are LGPL - so we can't compile it in by default. This is just on windows, and mac. The source distribution doesn't specify which one is used. cheers, On Thu, Mar 27, 2008 at 10:04 AM, James Paige <[EMAIL PROTECTED]> wrote: > Does anybody know whether pygame's version of SDl_mixer is compiled with > MAD or with SMPEG for mp3 support? > > Both of them are actually slightly buggy, although in different ways. > (IIRC, MAD was slightly better, but I could be remembering incorrectly) > > --- > James Paige > > > > On Wed, Mar 26, 2008 at 11:54:41PM +0100, Bo Jangeborg wrote: > > Another thing I found is that mp3 files often don't load for > > some reason and some time make pygame respond slowly. > > Maybe its hogging the event queue, I am not sure. > > > > Bo) > > > > Lenard Lindstrom skrev: > > >Thanks. This confirms what I have found. > > > > > >Lenard > > > > > > > > >Bo Jangeborg wrote: > > >>Aliens sounds good and used the following > > >>Video driver: windib > > >>Audio driver: dsound > > >> > > >>Lenard Lindstrom skrev: > > >>>To answer Brian, the default audio driver is dsound. SDL exports > > >>>function SDL_AudioDriverName. Maybe Pygame should wrap it. I found > > >>>and compiled a C space aliens game* that uses SDL, SDL_image and > > >>>SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, > > >>>channels 2, chunk size 3072. It is available on my Pygame page. Copy > > >>>the contents of the zip file into prebuilt\lib and run. It writes to > > >>>stderr.txt which drivers it uses. I suggest replacing the default > > >>>data\music.wav with something else as it is a noisy recording. > > >>> > > >>> > > > > > > > > > > >
Re: [pygame] vista testing...
Does anybody know whether pygame's version of SDl_mixer is compiled with MAD or with SMPEG for mp3 support? Both of them are actually slightly buggy, although in different ways. (IIRC, MAD was slightly better, but I could be remembering incorrectly) --- James Paige On Wed, Mar 26, 2008 at 11:54:41PM +0100, Bo Jangeborg wrote: > Another thing I found is that mp3 files often don't load for > some reason and some time make pygame respond slowly. > Maybe its hogging the event queue, I am not sure. > > Bo) > > Lenard Lindstrom skrev: > >Thanks. This confirms what I have found. > > > >Lenard > > > > > >Bo Jangeborg wrote: > >>Aliens sounds good and used the following > >>Video driver: windib > >>Audio driver: dsound > >> > >>Lenard Lindstrom skrev: > >>>To answer Brian, the default audio driver is dsound. SDL exports > >>>function SDL_AudioDriverName. Maybe Pygame should wrap it. I found > >>>and compiled a C space aliens game* that uses SDL, SDL_image and > >>>SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, > >>>channels 2, chunk size 3072. It is available on my Pygame page. Copy > >>>the contents of the zip file into prebuilt\lib and run. It writes to > >>>stderr.txt which drivers it uses. I suggest replacing the default > >>>data\music.wav with something else as it is a noisy recording. > >>> > >>> > > > > > >
Re: [pygame] vista testing...
mp3 support is not very good. It's based on the smpeg library which isn't very good. cheers, On Thu, Mar 27, 2008 at 9:54 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > Another thing I found is that mp3 files often don't load for > some reason and some time make pygame respond slowly. > Maybe its hogging the event queue, I am not sure. > > Bo) > > Lenard Lindstrom skrev: > > > > Thanks. This confirms what I have found. > > > > Lenard > > > > > > Bo Jangeborg wrote: > >> Aliens sounds good and used the following > >> Video driver: windib > >> Audio driver: dsound > >> > >> Lenard Lindstrom skrev: > >>> To answer Brian, the default audio driver is dsound. SDL exports > >>> function SDL_AudioDriverName. Maybe Pygame should wrap it. I found > >>> and compiled a C space aliens game* that uses SDL, SDL_image and > >>> SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, > >>> channels 2, chunk size 3072. It is available on my Pygame page. Copy > >>> the contents of the zip file into prebuilt\lib and run. It writes to > >>> stderr.txt which drivers it uses. I suggest replacing the default > >>> data\music.wav with something else as it is a noisy recording. > >>> > >>> > > > > > >
Re: [pygame] vista testing...
Another thing I found is that mp3 files often don't load for some reason and some time make pygame respond slowly. Maybe its hogging the event queue, I am not sure. Bo) Lenard Lindstrom skrev: Thanks. This confirms what I have found. Lenard Bo Jangeborg wrote: Aliens sounds good and used the following Video driver: windib Audio driver: dsound Lenard Lindstrom skrev: To answer Brian, the default audio driver is dsound. SDL exports function SDL_AudioDriverName. Maybe Pygame should wrap it. I found and compiled a C space aliens game* that uses SDL, SDL_image and SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, channels 2, chunk size 3072. It is available on my Pygame page. Copy the contents of the zip file into prebuilt\lib and run. It writes to stderr.txt which drivers it uses. I suggest replacing the default data\music.wav with something else as it is a noisy recording.
Re: [pygame] vista testing...
Thanks. This confirms what I have found. Lenard Bo Jangeborg wrote: Aliens sounds good and used the following Video driver: windib Audio driver: dsound Lenard Lindstrom skrev: To answer Brian, the default audio driver is dsound. SDL exports function SDL_AudioDriverName. Maybe Pygame should wrap it. I found and compiled a C space aliens game* that uses SDL, SDL_image and SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, channels 2, chunk size 3072. It is available on my Pygame page. Copy the contents of the zip file into prebuilt\lib and run. It writes to stderr.txt which drivers it uses. I suggest replacing the default data\music.wav with something else as it is a noisy recording.
Re: [pygame] vista testing...
Aliens sounds good and used the following Video driver: windib Audio driver: dsound Lenard Lindstrom skrev: To answer Brian, the default audio driver is dsound. SDL exports function SDL_AudioDriverName. Maybe Pygame should wrap it. I found and compiled a C space aliens game* that uses SDL, SDL_image and SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, channels 2, chunk size 3072. It is available on my Pygame page. Copy the contents of the zip file into prebuilt\lib and run. It writes to stderr.txt which drivers it uses. I suggest replacing the default data\music.wav with something else as it is a noisy recording. Lenard * aliens-1.0.2 found at http://www.libsdl.org/projects/aliens/ md5sum 69af2fcb372aa7f4668db64750b428ab *aliens-1.0.2.zip Maybe this is the inspiration for the aliens game included with the Pygame examples. René Dudfield wrote: Cool. Seems like we're getting closer to figuring this thing out... Two more tests to try: 1. Try with the dummy video driver to see if there are still scratchy noises. import os os.environ['SDL_VIDEODRIVER'] = 'dummy' This will tell us if a video driver is having an effect. 2. try pygame program with a 4096 sized buffer. This will let us know that a 4096 sized buffer magically works better :) cu, On Wed, Mar 26, 2008 at 12:45 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: the fact that playmus SDL_Init(SDL_INIT_AUDIO) is interesting - I wonder if having a window or not affects whether playmus can use the dsound backend? How would one figure out what audio backend SDL chose? On Tue, Mar 25, 2008 at 5:06 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Two things I noted with playmus. First it initializes SDL with > SDL_Init(SDL_INIT_AUDIO). Second it starts playback with > Mix_FadeInMusic(music,looping,2000). It lacks a feature to start > playback in the middle of a song unfortunately. > > >
Re: [pygame] vista testing...
Opened audio at 44100 Hz 16 bit stereo (LE), 4096 bytes audio buffer Playing Intro_Theme.ogg playwave seem to be working ok too. Lenard Lindstrom skrev: Audio defaults to dsound (DirectX). The other available Windows setting for SDL_AUDIODRIVER is waveout *. What playmus tells us is streaming audio (pygame.mixer.music) is working for SDL. I have another program, playwave, that tests channels (pygame.mixer). I have uploaded it to my site where the dependencies are: http://www3.telus.net/len_l/pygame.htm md5sum 856cd257346a8700d0aa2e1792130b21 *playwave.zip It may be useful to compare with playmus. It works the same way. Thanks for the testing. Lenard * ftp://ptah.lnf.kth.se/pub/misc/sdl-env-vars gives a listing of environment variables recognized by SDL. Bo Jangeborg wrote: playmus plays ok here Opened audio at 44100 Hz 16 bit stereo (LE), 3072 bytes audio buffer Playing Intro_Theme.ogg Does it default to dsound ? I tried to set the computer enviroment variable to SDL_AUDIODRIVER dsound. Is there another place were I should set it ? Lenard Lindstrom skrev: Hi Bo, SDL 1.2 uses DirectX 5. This may not be properly supported on Vista. I am surprised SDL audio defaults to it rather than waveout. Anyway, to check if it is a Pygame problem it would be useful if you could test SDL directly. I understand you have downloaded the prebuilts from www3.telus.net/len_l. If so then you will find in prebuilt\lib the playmus program. Everything needed by playmus.exe is in the directory except msvcr71.dll, which can be copied to prebuilt\lib from Python's root directory. playmus is a console program. It writes output to files stdout.txt and stderr.txt rather than the screen. To list command line options just run playmus without any options and look in stderr.txt. The settings it uses when playing a music file are written to stdout.txt. Here is a list of relevant options: playmus [-r rate] [-b bytes] -r playback rate: eg. 44100 or 22050 -b buffer size: eg 4096 - the default It would be useful to try playing some files with 44100 to see how they sound. If the sound is scratchy then try it with SDL_AUDIODRIVER set to waveout. Thanks, Lenard
Re: [pygame] vista testing...
To answer Brian, the default audio driver is dsound. SDL exports function SDL_AudioDriverName. Maybe Pygame should wrap it. I found and compiled a C space aliens game* that uses SDL, SDL_image and SDL_mixer. I altered it to use frequency 44100, format AUDIO_S16, channels 2, chunk size 3072. It is available on my Pygame page. Copy the contents of the zip file into prebuilt\lib and run. It writes to stderr.txt which drivers it uses. I suggest replacing the default data\music.wav with something else as it is a noisy recording. Lenard * aliens-1.0.2 found at http://www.libsdl.org/projects/aliens/ md5sum 69af2fcb372aa7f4668db64750b428ab *aliens-1.0.2.zip Maybe this is the inspiration for the aliens game included with the Pygame examples. René Dudfield wrote: Cool. Seems like we're getting closer to figuring this thing out... Two more tests to try: 1. Try with the dummy video driver to see if there are still scratchy noises. import os os.environ['SDL_VIDEODRIVER'] = 'dummy' This will tell us if a video driver is having an effect. 2. try pygame program with a 4096 sized buffer. This will let us know that a 4096 sized buffer magically works better :) cu, On Wed, Mar 26, 2008 at 12:45 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: the fact that playmus SDL_Init(SDL_INIT_AUDIO) is interesting - I wonder if having a window or not affects whether playmus can use the dsound backend? How would one figure out what audio backend SDL chose? On Tue, Mar 25, 2008 at 5:06 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Two things I noted with playmus. First it initializes SDL with > SDL_Init(SDL_INIT_AUDIO). Second it starts playback with > Mix_FadeInMusic(music,looping,2000). It lacks a feature to start > playback in the middle of a song unfortunately. > > >
Re: [pygame] vista testing...
Cool. Seems like we're getting closer to figuring this thing out... Two more tests to try: 1. Try with the dummy video driver to see if there are still scratchy noises. import os os.environ['SDL_VIDEODRIVER'] = 'dummy' This will tell us if a video driver is having an effect. 2. try pygame program with a 4096 sized buffer. This will let us know that a 4096 sized buffer magically works better :) cu, On Wed, Mar 26, 2008 at 12:45 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > the fact that playmus SDL_Init(SDL_INIT_AUDIO) is interesting - I > wonder if having a window or not affects whether playmus can use the > dsound backend? How would one figure out what audio backend SDL chose? > > > > On Tue, Mar 25, 2008 at 5:06 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > > Two things I noted with playmus. First it initializes SDL with > > SDL_Init(SDL_INIT_AUDIO). Second it starts playback with > > Mix_FadeInMusic(music,looping,2000). It lacks a feature to start > > playback in the middle of a song unfortunately. > > > > > > Lenard > > > > > > > > > > René Dudfield wrote: > > > Hello, > > > > > > Yeah, it would be very useful if you could try the playmus program to > > > try and reproduce your problem. This will help with a bug report to > > > SDL. > > > > > > It would also help if we could summarise all your testing to make a > > > better SDL bug report. eg. > > > I tried this, then this, then this, then this, etc. > > > > > > > > > > > > Note that Bo is using windows XP. > > > > > > I don't think it's a bug in directx, but a change in the way threads > > > work from win98 to winxp - exposing a bug in the sdl code. > > > > > > That sound code in SDL was mostly written in the time of win9x, and > win2k. > > > > > > I think the change in the video driver has also changed the behaviour > > > of the thread code for the sound. Since using windib for video > > > changes the amount of cpu time used in the sound threads and also the > > > properties of the video thread. > > > > > > > > > > > >
Re: [pygame] vista testing...
the fact that playmus SDL_Init(SDL_INIT_AUDIO) is interesting - I wonder if having a window or not affects whether playmus can use the dsound backend? How would one figure out what audio backend SDL chose? On Tue, Mar 25, 2008 at 5:06 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Two things I noted with playmus. First it initializes SDL with > SDL_Init(SDL_INIT_AUDIO). Second it starts playback with > Mix_FadeInMusic(music,looping,2000). It lacks a feature to start > playback in the middle of a song unfortunately. > > > Lenard > > > > > René Dudfield wrote: > > Hello, > > > > Yeah, it would be very useful if you could try the playmus program to > > try and reproduce your problem. This will help with a bug report to > > SDL. > > > > It would also help if we could summarise all your testing to make a > > better SDL bug report. eg. > > I tried this, then this, then this, then this, etc. > > > > > > > > Note that Bo is using windows XP. > > > > I don't think it's a bug in directx, but a change in the way threads > > work from win98 to winxp - exposing a bug in the sdl code. > > > > That sound code in SDL was mostly written in the time of win9x, and win2k. > > > > I think the change in the video driver has also changed the behaviour > > of the thread code for the sound. Since using windib for video > > changes the amount of cpu time used in the sound threads and also the > > properties of the video thread. > > > > > > >
Re: [pygame] vista testing...
Two things I noted with playmus. First it initializes SDL with SDL_Init(SDL_INIT_AUDIO). Second it starts playback with Mix_FadeInMusic(music,looping,2000). It lacks a feature to start playback in the middle of a song unfortunately. Lenard René Dudfield wrote: Hello, Yeah, it would be very useful if you could try the playmus program to try and reproduce your problem. This will help with a bug report to SDL. It would also help if we could summarise all your testing to make a better SDL bug report. eg. I tried this, then this, then this, then this, etc. Note that Bo is using windows XP. I don't think it's a bug in directx, but a change in the way threads work from win98 to winxp - exposing a bug in the sdl code. That sound code in SDL was mostly written in the time of win9x, and win2k. I think the change in the video driver has also changed the behaviour of the thread code for the sound. Since using windib for video changes the amount of cpu time used in the sound threads and also the properties of the video thread.
Re: [pygame] vista testing...
Audio defaults to dsound (DirectX). The other available Windows setting for SDL_AUDIODRIVER is waveout *. What playmus tells us is streaming audio (pygame.mixer.music) is working for SDL. I have another program, playwave, that tests channels (pygame.mixer). I have uploaded it to my site where the dependencies are: http://www3.telus.net/len_l/pygame.htm md5sum 856cd257346a8700d0aa2e1792130b21 *playwave.zip It may be useful to compare with playmus. It works the same way. Thanks for the testing. Lenard * ftp://ptah.lnf.kth.se/pub/misc/sdl-env-vars gives a listing of environment variables recognized by SDL. Bo Jangeborg wrote: playmus plays ok here Opened audio at 44100 Hz 16 bit stereo (LE), 3072 bytes audio buffer Playing Intro_Theme.ogg Does it default to dsound ? I tried to set the computer enviroment variable to SDL_AUDIODRIVER dsound. Is there another place were I should set it ? Lenard Lindstrom skrev: Hi Bo, SDL 1.2 uses DirectX 5. This may not be properly supported on Vista. I am surprised SDL audio defaults to it rather than waveout. Anyway, to check if it is a Pygame problem it would be useful if you could test SDL directly. I understand you have downloaded the prebuilts from www3.telus.net/len_l. If so then you will find in prebuilt\lib the playmus program. Everything needed by playmus.exe is in the directory except msvcr71.dll, which can be copied to prebuilt\lib from Python's root directory. playmus is a console program. It writes output to files stdout.txt and stderr.txt rather than the screen. To list command line options just run playmus without any options and look in stderr.txt. The settings it uses when playing a music file are written to stdout.txt. Here is a list of relevant options: playmus [-r rate] [-b bytes] -r playback rate: eg. 44100 or 22050 -b buffer size: eg 4096 - the default It would be useful to try playing some files with 44100 to see how they sound. If the sound is scratchy then try it with SDL_AUDIODRIVER set to waveout. Thanks, Lenard
Re: [pygame] vista testing...
playmus plays ok here Opened audio at 44100 Hz 16 bit stereo (LE), 3072 bytes audio buffer Playing Intro_Theme.ogg Does it default to dsound ? I tried to set the computer enviroment variable to SDL_AUDIODRIVER dsound. Is there another place were I should set it ? Lenard Lindstrom skrev: Hi Bo, SDL 1.2 uses DirectX 5. This may not be properly supported on Vista. I am surprised SDL audio defaults to it rather than waveout. Anyway, to check if it is a Pygame problem it would be useful if you could test SDL directly. I understand you have downloaded the prebuilts from www3.telus.net/len_l. If so then you will find in prebuilt\lib the playmus program. Everything needed by playmus.exe is in the directory except msvcr71.dll, which can be copied to prebuilt\lib from Python's root directory. playmus is a console program. It writes output to files stdout.txt and stderr.txt rather than the screen. To list command line options just run playmus without any options and look in stderr.txt. The settings it uses when playing a music file are written to stdout.txt. Here is a list of relevant options: playmus [-r rate] [-b bytes] -r playback rate: eg. 44100 or 22050 -b buffer size: eg 4096 - the default It would be useful to try playing some files with 44100 to see how they sound. If the sound is scratchy then try it with SDL_AUDIODRIVER set to waveout. Thanks, Lenard Bo Jangeborg wrote: OK , 'waveout' works. I thought I tested that the other day but I must have put in the statement too far down. The number of channels does not affect things. With 'waveout' I can use a 1k buffer and it still sounds good. I still have the occasional scratching if a skip forward in the file. Interesting note , the scratching is reoccurring at the same frequency. But it doesn't happen every time I skip forward. The length of the buffer does not seem to affect the frequency of this scratch, maybe the bufferpointer gets moved ahead of the buffer and picks up trash and then keeps going back to that point. Using pygame.mixer.pre_init(11025, -16, 2, 512) and skiping ahead in file I still get the scratch. But occasionally I now get pure static witch would point to the bufferpointer getting moved to the wrong spot. René Dudfield skrev: Hello, could you also please try the different audio drivers? import os if 1: # directx os.environ['SDL_AUDIODRIVER'] = 'dsound' else: # waveout os.environ['SDL_AUDIODRIVER'] = 'waveout' cheers, On Tue, Mar 25, 2008 at 4:26 PM, René Dudfield <[EMAIL PROTECTED]> wrote: hrmm. Can you try using less channels to see if that has an effect? pygame.mixer.set_num_channels(4)
Re: [pygame] vista testing...
Hello, Yeah, it would be very useful if you could try the playmus program to try and reproduce your problem. This will help with a bug report to SDL. It would also help if we could summarise all your testing to make a better SDL bug report. eg. I tried this, then this, then this, then this, etc. Note that Bo is using windows XP. I don't think it's a bug in directx, but a change in the way threads work from win98 to winxp - exposing a bug in the sdl code. That sound code in SDL was mostly written in the time of win9x, and win2k. I think the change in the video driver has also changed the behaviour of the thread code for the sound. Since using windib for video changes the amount of cpu time used in the sound threads and also the properties of the video thread. cheers, On Wed, Mar 26, 2008 at 6:00 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Hi Bo, > > SDL 1.2 uses DirectX 5. This may not be properly supported on Vista. I > am surprised SDL audio defaults to it rather than waveout. Anyway, to > check if it is a Pygame problem it would be useful if you could test SDL > directly. I understand you have downloaded the prebuilts from > www3.telus.net/len_l. If so then you will find in prebuilt\lib the > playmus program. Everything needed by playmus.exe is in the directory > except msvcr71.dll, which can be copied to prebuilt\lib from Python's > root directory. > > playmus is a console program. It writes output to files stdout.txt and > stderr.txt rather than the screen. To list command line options just > run playmus without any options and look in stderr.txt. The settings it > uses when playing a music file are written to stdout.txt. Here is a list > of relevant options: > > playmus [-r rate] [-b bytes] > -r playback rate: eg. 44100 or 22050 > -b buffer size: eg 4096 - the default > > It would be useful to try playing some files with 44100 to see how they > sound. If the sound is scratchy then try it with SDL_AUDIODRIVER set to > waveout. > > Thanks, > > Lenard > > > > > Bo Jangeborg wrote: > > OK , 'waveout' works. I thought I tested that the other day but > > I must have put in the statement too far down. The number of channels > > does not affect things. With 'waveout' I can use a 1k buffer and it > > still sounds > > good. > > > > I still have the occasional scratching if a skip forward in the file. > > Interesting note , the scratching is reoccurring at the same frequency. > > But it doesn't happen every time I skip forward. > > The length of the buffer does not seem to affect the frequency of this > > scratch, > > maybe the bufferpointer gets moved ahead of the buffer and picks up > > trash and then > > keeps going back to that point. > > Using pygame.mixer.pre_init(11025, -16, 2, 512) and skiping ahead in file > > I still get the scratch. But occasionally I now get pure static witch > > would > > point to the bufferpointer getting moved to the wrong spot. > > > > René Dudfield skrev: > >> Hello, > >> > >> could you also please try the different audio drivers? > >> > >> import os > >> if 1: > >> # directx > >> os.environ['SDL_AUDIODRIVER'] = 'dsound' > >> else: > >> # waveout > >> os.environ['SDL_AUDIODRIVER'] = 'waveout' > >> > >> > >> cheers, > >> > >> > >> On Tue, Mar 25, 2008 at 4:26 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > >> > >>> hrmm. > >>> > >>> Can you try using less channels to see if that has an effect? > >>> > >>> pygame.mixer.set_num_channels(4) > >>> > >>> > > > > > -- > > > Lenard Lindstrom > <[EMAIL PROTECTED]> > >
Re: [pygame] vista testing...
Hi Bo, SDL 1.2 uses DirectX 5. This may not be properly supported on Vista. I am surprised SDL audio defaults to it rather than waveout. Anyway, to check if it is a Pygame problem it would be useful if you could test SDL directly. I understand you have downloaded the prebuilts from www3.telus.net/len_l. If so then you will find in prebuilt\lib the playmus program. Everything needed by playmus.exe is in the directory except msvcr71.dll, which can be copied to prebuilt\lib from Python's root directory. playmus is a console program. It writes output to files stdout.txt and stderr.txt rather than the screen. To list command line options just run playmus without any options and look in stderr.txt. The settings it uses when playing a music file are written to stdout.txt. Here is a list of relevant options: playmus [-r rate] [-b bytes] -r playback rate: eg. 44100 or 22050 -b buffer size: eg 4096 - the default It would be useful to try playing some files with 44100 to see how they sound. If the sound is scratchy then try it with SDL_AUDIODRIVER set to waveout. Thanks, Lenard Bo Jangeborg wrote: OK , 'waveout' works. I thought I tested that the other day but I must have put in the statement too far down. The number of channels does not affect things. With 'waveout' I can use a 1k buffer and it still sounds good. I still have the occasional scratching if a skip forward in the file. Interesting note , the scratching is reoccurring at the same frequency. But it doesn't happen every time I skip forward. The length of the buffer does not seem to affect the frequency of this scratch, maybe the bufferpointer gets moved ahead of the buffer and picks up trash and then keeps going back to that point. Using pygame.mixer.pre_init(11025, -16, 2, 512) and skiping ahead in file I still get the scratch. But occasionally I now get pure static witch would point to the bufferpointer getting moved to the wrong spot. René Dudfield skrev: Hello, could you also please try the different audio drivers? import os if 1: # directx os.environ['SDL_AUDIODRIVER'] = 'dsound' else: # waveout os.environ['SDL_AUDIODRIVER'] = 'waveout' cheers, On Tue, Mar 25, 2008 at 4:26 PM, René Dudfield <[EMAIL PROTECTED]> wrote: hrmm. Can you try using less channels to see if that has an effect? pygame.mixer.set_num_channels(4) -- Lenard Lindstrom <[EMAIL PROTECTED]>
Re: [pygame] vista testing...
Hi Doug,
Of course, I forgot! How stupid, just one of those UNIX things that when
never using that stuff any more, you forget. I should have known, but when
half asleep when writing it and testing it, it is easy to forget. It had
been months since I had an issue of using control chars and such. Makes
complete sense now.
Now I have to clean up my game and get the help menu score card stuff up
in a F key and fix the computer look-ahead turn and such.
It works fine as is for playing with just the toggle back and forth.
Bruce
Bruce,
It looks like you are mixing Windows paths (backslash) with Python
strings. "\awe" means something different from "\\awe". Python strings
are pretty smart in figuring out what you mean, but can't do it in all
cases. \a means, I think, "ring the bell"; \n is newline, etc.
I think if you use a single forward slash, or double backslash you'll be ok.
-Doug
FT wrote:
> Hi Lenard
>
> your not going to believe this after extensive testing, what was
needed
> was the import os.path for that file and only that file would not play
> without the path.
>
> I am not joking about this, for I tested all the files inside the data
> folder from the folder above and all would work but the Awes file. But
when
> placing that file in the same directory as the .py file it worked. So I
> decided to insert the os.path.join() into the file name for the mixer and
it
> worked. It runs now without any problem.
>
> So, the question to ask is why only that file? No other file inside
the
> data folder had an error and I have all sizes and shapes being run in my
> battleship program. All them on the list have the "data\name" filename
> inside the .mixer assignment. But only the awes file would say mixer load
> error of no src, for it could not find the file.
>
> Talk about weird situations. So your test below failed until I added
the
> os.path command. I inserted it into my battle.py game and it works now.
> Later I will do the assignments inside a method.
>
> The game is attached with the awe file inside the boohoo name. I guess
> you could use your own files for sound unless I send it zipped up.
>
> Bruce
>
> Without calling pygame.mixer.pre_init the mixer defaults to a 22050
> sample rate and a 3072 byte buffer. The following test program played
> the attached wave file with problem.
>
>
> import pygame
>
> pygame.init()
>
> sound = pygame.mixer.Sound("Awes.wav")
> sound.play()
>
> while pygame.mixer.get_busy():
> pass
>
>
> Lenard
>
>
> FT wrote:
>> Hi!
>> I am not sure if this is related because I do not get any scratching
> on
>> my sounds when I only use pygame.init with no mixer init but the attached
>> file, the only one of the bunch I have will not play at all. In fact it
> says
>> error, no src. Also it says it is a null file.
>> It is an 8 bit, 88K but I have many like this one but they play with
> no
>> problems or scratching. I use both 8 bit and 16 bit and one is played
>> continuously, but this one dies once assigned with the null, no src
error.
>>
>> So, what is the difference in this file from all others when trying
to
>> play it with the mixer? You have to convert it back to a .wav file for
the
>> list rejected with the extension on it, so I sent it without it.
>>
>> I am using pygame 1.8 rc 3 and SDL (1,2,12)
>>
>> Bruce
>>
>>
>> When you say "that didn't work at all", what exactly do you mean? What
>> SDL prebuilts were you running with what pygame when you had a
>> problem?
>>
>> In terms of not working - do you mean you get a python exception? seg
>> fault? stuff seemed to work but no sound played?
>>
>> Also, while I haven't tried an older SDL with pygame 1.8. I've
>> successfully used the newer SDL dll's with pygame 1.7.
>>
>> So if the problems you had were trying to run the SDL from 1.7 with
>> pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL
>> dll's here:
>> http://www3.telus.net/len_l/prebuilt-msvcr71.zip
>> the result of that one test case will provide useful info on if this
>> is an SDL bug or not.
>>
>>
>> On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote:
>>
>>> Did try that yesterday but that didn't work at all.
>>> I don't think the different versions of the mixer are
>>> compatible.
>>>
>>> Brian Fisher skrev:
>>>
>>>
>>>
One other thing to try would be to swap out different SDL library
>>> > versions. Pygame 1.8 includes newer SDL library versions than 1.7
>>> > does, I think SDL mixer was updated as part of that.
>>> >
>>> > You should be able switch being using the dll's for 1.7 here:
>>> > http://pygame.org/ftp/win32-dependencies.zip
>>> >
>>> > and the dll's for 1.8 here:
>>> > http://www3.telus.net/len_l/prebuilt-msvcr71.zip
>>> >
>>> > just by copying the dll's over the ones in your site-packages/pygame
>>>
>> dir.
>>
>>> >
>>> > so if you get scratchiness in both pygame 1.7 & 1.8 with the newer
SDL
>>> > but not with t
Re: [pygame] vista testing...
Bruce,
It looks like you are mixing Windows paths (backslash) with Python
strings. "\awe" means something different from "\\awe". Python strings
are pretty smart in figuring out what you mean, but can't do it in all
cases. \a means, I think, "ring the bell"; \n is newline, etc.
I think if you use a single forward slash, or double backslash you'll be ok.
-Doug
FT wrote:
Hi Lenard
your not going to believe this after extensive testing, what was needed
was the import os.path for that file and only that file would not play
without the path.
I am not joking about this, for I tested all the files inside the data
folder from the folder above and all would work but the Awes file. But when
placing that file in the same directory as the .py file it worked. So I
decided to insert the os.path.join() into the file name for the mixer and it
worked. It runs now without any problem.
So, the question to ask is why only that file? No other file inside the
data folder had an error and I have all sizes and shapes being run in my
battleship program. All them on the list have the "data\name" filename
inside the .mixer assignment. But only the awes file would say mixer load
error of no src, for it could not find the file.
Talk about weird situations. So your test below failed until I added the
os.path command. I inserted it into my battle.py game and it works now.
Later I will do the assignments inside a method.
The game is attached with the awe file inside the boohoo name. I guess
you could use your own files for sound unless I send it zipped up.
Bruce
Without calling pygame.mixer.pre_init the mixer defaults to a 22050
sample rate and a 3072 byte buffer. The following test program played
the attached wave file with problem.
import pygame
pygame.init()
sound = pygame.mixer.Sound("Awes.wav")
sound.play()
while pygame.mixer.get_busy():
pass
Lenard
FT wrote:
Hi!
I am not sure if this is related because I do not get any scratching
on
my sounds when I only use pygame.init with no mixer init but the attached
file, the only one of the bunch I have will not play at all. In fact it
says
error, no src. Also it says it is a null file.
It is an 8 bit, 88K but I have many like this one but they play with
no
problems or scratching. I use both 8 bit and 16 bit and one is played
continuously, but this one dies once assigned with the null, no src error.
So, what is the difference in this file from all others when trying to
play it with the mixer? You have to convert it back to a .wav file for the
list rejected with the extension on it, so I sent it without it.
I am using pygame 1.8 rc 3 and SDL (1,2,12)
Bruce
When you say "that didn't work at all", what exactly do you mean? What
SDL prebuilts were you running with what pygame when you had a
problem?
In terms of not working - do you mean you get a python exception? seg
fault? stuff seemed to work but no sound played?
Also, while I haven't tried an older SDL with pygame 1.8. I've
successfully used the newer SDL dll's with pygame 1.7.
So if the problems you had were trying to run the SDL from 1.7 with
pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL
dll's here:
http://www3.telus.net/len_l/prebuilt-msvcr71.zip
the result of that one test case will provide useful info on if this
is an SDL bug or not.
On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote:
Did try that yesterday but that didn't work at all.
I don't think the different versions of the mixer are
compatible.
Brian Fisher skrev:
One other thing to try would be to swap out different SDL library
> versions. Pygame 1.8 includes newer SDL library versions than 1.7
> does, I think SDL mixer was updated as part of that.
>
> You should be able switch being using the dll's for 1.7 here:
> http://pygame.org/ftp/win32-dependencies.zip
>
> and the dll's for 1.8 here:
> http://www3.telus.net/len_l/prebuilt-msvcr71.zip
>
> just by copying the dll's over the ones in your site-packages/pygame
dir.
>
> so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL
> but not with the older SDL, it would seem to be a new SDL bug. if you
> get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7
> with either SDL, then it would seem to be something pygame introduced.
>
>
> On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote:
>
>> Just tried it, no differens I am afraid. One thing I noticed , and
that
>> was true for
>> the mingw version too, was that at 44k the music was running
>> considerally slower.
>> Not sure if that's any clue.
>> Is the interrrupt not frequent enough for it to pump out the music ?
Or
>> what do
>> think is happening here. Do you have any compiler options to play
around
>> with ?
>>
>> René Dudfield skrev:
>>
>>
>>
>>> Are you able to try the pygame from here ?
>>>
>> > http://thorbrian.
Re: [pygame] vista testing...
Hi Lenard
your not going to believe this after extensive testing, what was needed
was the import os.path for that file and only that file would not play
without the path.
I am not joking about this, for I tested all the files inside the data
folder from the folder above and all would work but the Awes file. But when
placing that file in the same directory as the .py file it worked. So I
decided to insert the os.path.join() into the file name for the mixer and it
worked. It runs now without any problem.
So, the question to ask is why only that file? No other file inside the
data folder had an error and I have all sizes and shapes being run in my
battleship program. All them on the list have the "data\name" filename
inside the .mixer assignment. But only the awes file would say mixer load
error of no src, for it could not find the file.
Talk about weird situations. So your test below failed until I added the
os.path command. I inserted it into my battle.py game and it works now.
Later I will do the assignments inside a method.
The game is attached with the awe file inside the boohoo name. I guess
you could use your own files for sound unless I send it zipped up.
Bruce
Without calling pygame.mixer.pre_init the mixer defaults to a 22050
sample rate and a 3072 byte buffer. The following test program played
the attached wave file with problem.
import pygame
pygame.init()
sound = pygame.mixer.Sound("Awes.wav")
sound.play()
while pygame.mixer.get_busy():
pass
Lenard
FT wrote:
> Hi!
> I am not sure if this is related because I do not get any scratching
on
> my sounds when I only use pygame.init with no mixer init but the attached
> file, the only one of the bunch I have will not play at all. In fact it
says
> error, no src. Also it says it is a null file.
> It is an 8 bit, 88K but I have many like this one but they play with
no
> problems or scratching. I use both 8 bit and 16 bit and one is played
> continuously, but this one dies once assigned with the null, no src error.
>
> So, what is the difference in this file from all others when trying to
> play it with the mixer? You have to convert it back to a .wav file for the
> list rejected with the extension on it, so I sent it without it.
>
> I am using pygame 1.8 rc 3 and SDL (1,2,12)
>
> Bruce
>
>
> When you say "that didn't work at all", what exactly do you mean? What
> SDL prebuilts were you running with what pygame when you had a
> problem?
>
> In terms of not working - do you mean you get a python exception? seg
> fault? stuff seemed to work but no sound played?
>
> Also, while I haven't tried an older SDL with pygame 1.8. I've
> successfully used the newer SDL dll's with pygame 1.7.
>
> So if the problems you had were trying to run the SDL from 1.7 with
> pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL
> dll's here:
> http://www3.telus.net/len_l/prebuilt-msvcr71.zip
> the result of that one test case will provide useful info on if this
> is an SDL bug or not.
>
>
> On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote:
>
>> Did try that yesterday but that didn't work at all.
>> I don't think the different versions of the mixer are
>> compatible.
>>
>> Brian Fisher skrev:
>>
>>
>>
>>> One other thing to try would be to swap out different SDL library
>>>
>> > versions. Pygame 1.8 includes newer SDL library versions than 1.7
>> > does, I think SDL mixer was updated as part of that.
>> >
>> > You should be able switch being using the dll's for 1.7 here:
>> > http://pygame.org/ftp/win32-dependencies.zip
>> >
>> > and the dll's for 1.8 here:
>> > http://www3.telus.net/len_l/prebuilt-msvcr71.zip
>> >
>> > just by copying the dll's over the ones in your site-packages/pygame
>>
> dir.
>
>> >
>> > so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL
>> > but not with the older SDL, it would seem to be a new SDL bug. if you
>> > get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7
>> > with either SDL, then it would seem to be something pygame introduced.
>> >
>> >
>> > On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote:
>> >
>> >> Just tried it, no differens I am afraid. One thing I noticed , and
>>
> that
>
>> >> was true for
>> >> the mingw version too, was that at 44k the music was running
>> >> considerally slower.
>> >> Not sure if that's any clue.
>> >> Is the interrrupt not frequent enough for it to pump out the music ?
>>
> Or
>
>> >> what do
>> >> think is happening here. Do you have any compiler options to play
>>
> around
>
>> >> with ?
>> >>
>> >> René Dudfield skrev:
>> >>
>> >>
>> >>
>> >>> Are you able to try the pygame from here ?
>> >>>
>> >> > http://thorbrian.com/pygame/builds.php
>> >> >
>> >> > I think this is compiled with visual C rather than mingw, so maybe
>> >> > it'll be different...
>> >> >
>> >> > cheers,
>> >> >
>>
Re: [pygame] vista testing...
OK , 'waveout' works. I thought I tested that the other day but I must have put in the statement too far down. The number of channels does not affect things. With 'waveout' I can use a 1k buffer and it still sounds good. I still have the occasional scratching if a skip forward in the file. Interesting note , the scratching is reoccurring at the same frequency. But it doesn't happen every time I skip forward. The length of the buffer does not seem to affect the frequency of this scratch, maybe the bufferpointer gets moved ahead of the buffer and picks up trash and then keeps going back to that point. Using pygame.mixer.pre_init(11025, -16, 2, 512) and skiping ahead in file I still get the scratch. But occasionally I now get pure static witch would point to the bufferpointer getting moved to the wrong spot. René Dudfield skrev: Hello, could you also please try the different audio drivers? import os if 1: # directx os.environ['SDL_AUDIODRIVER'] = 'dsound' else: # waveout os.environ['SDL_AUDIODRIVER'] = 'waveout' cheers, On Tue, Mar 25, 2008 at 4:26 PM, René Dudfield <[EMAIL PROTECTED]> wrote: hrmm. Can you try using less channels to see if that has an effect? pygame.mixer.set_num_channels(4)
Re: [pygame] vista testing...
with the release version, pygame 1.7 links to msvcr71.dll while the sdl dlls link to msvcrt.dll, and they run together fine except for opening things from file-like objects, so as long as you don't do that, the sdl version should be interoperable Here are builds of the same versions of sdl that pygame 1.7 uses that don't have a c runtime version problem: http://thorbrian.com/SDLDependenciesUsingMSVCR71.zip On Mon, Mar 24, 2008 at 10:32 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > The 1.7 and 1.8 dependencies are linked to a different C library, > msvcrt.dll and msvcr71.dll respectively. It is quite likely they will > not work together. > > Lenard >
Re: [pygame] vista testing...
Without calling pygame.mixer.pre_init the mixer defaults to a 22050
sample rate and a 3072 byte buffer. The following test program played
the attached wave file with problem.
import pygame
pygame.init()
sound = pygame.mixer.Sound("Awes.wav")
sound.play()
while pygame.mixer.get_busy():
pass
Lenard
FT wrote:
Hi!
I am not sure if this is related because I do not get any scratching on
my sounds when I only use pygame.init with no mixer init but the attached
file, the only one of the bunch I have will not play at all. In fact it says
error, no src. Also it says it is a null file.
It is an 8 bit, 88K but I have many like this one but they play with no
problems or scratching. I use both 8 bit and 16 bit and one is played
continuously, but this one dies once assigned with the null, no src error.
So, what is the difference in this file from all others when trying to
play it with the mixer? You have to convert it back to a .wav file for the
list rejected with the extension on it, so I sent it without it.
I am using pygame 1.8 rc 3 and SDL (1,2,12)
Bruce
When you say "that didn't work at all", what exactly do you mean? What
SDL prebuilts were you running with what pygame when you had a
problem?
In terms of not working - do you mean you get a python exception? seg
fault? stuff seemed to work but no sound played?
Also, while I haven't tried an older SDL with pygame 1.8. I've
successfully used the newer SDL dll's with pygame 1.7.
So if the problems you had were trying to run the SDL from 1.7 with
pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL
dll's here:
http://www3.telus.net/len_l/prebuilt-msvcr71.zip
the result of that one test case will provide useful info on if this
is an SDL bug or not.
On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote:
Did try that yesterday but that didn't work at all.
I don't think the different versions of the mixer are
compatible.
Brian Fisher skrev:
One other thing to try would be to swap out different SDL library
> versions. Pygame 1.8 includes newer SDL library versions than 1.7
> does, I think SDL mixer was updated as part of that.
>
> You should be able switch being using the dll's for 1.7 here:
> http://pygame.org/ftp/win32-dependencies.zip
>
> and the dll's for 1.8 here:
> http://www3.telus.net/len_l/prebuilt-msvcr71.zip
>
> just by copying the dll's over the ones in your site-packages/pygame
dir.
>
> so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL
> but not with the older SDL, it would seem to be a new SDL bug. if you
> get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7
> with either SDL, then it would seem to be something pygame introduced.
>
>
> On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote:
>
>> Just tried it, no differens I am afraid. One thing I noticed , and
that
>> was true for
>> the mingw version too, was that at 44k the music was running
>> considerally slower.
>> Not sure if that's any clue.
>> Is the interrrupt not frequent enough for it to pump out the music ?
Or
>> what do
>> think is happening here. Do you have any compiler options to play
around
>> with ?
>>
>> René Dudfield skrev:
>>
>>
>>
>>> Are you able to try the pygame from here ?
>>>
>> > http://thorbrian.com/pygame/builds.php
>> >
>> > I think this is compiled with visual C rather than mingw, so maybe
>> > it'll be different...
>> >
>> > cheers,
>> >
>> > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]>
wrote:
>> >
>> >> The scratching are with all music files I have tested. The music
have a
>> >> native sample rate
>> >> of 44k so there should be no need to resample, and it does work
when the
>> >> output is changed
>> >> to 22k. I have tested with 15 different pieces. Furthermore it
worked ok
>> >> in pygame 1.7.
>> >>
>> >> If I start a bit into the music I get occasional scratching for
the rest
>> >> of the piece after that.
>> >>
>> >> Brian Fisher skrev:
>> >>
>> >>
>> >>
>> >>> The change with sample rate makes me think it may actually have
to do
>> >>>
>> >> > with the particular sound samples as well? I understand that
SDL is
>> >> > somewhat limited on the sample rate conversions it supports -
got
>> >> > particular sounds files that sound scratchy you can send to
test with?
>> >> >
>> >> > also, when you say you get scratches after starting some way
into the
>> >> > music - do you mean you get like a pop when first playing the
music,
>> >> > or do you mean that you get scratches throughout the music
after you
>> >> > start it playing at a point in the sound?
>> >> >
>> >> >
>> >> > On Sun, Mar 23, 2008 at 2:27 PM,
Re: [pygame] vista testing...
The 1.7 and 1.8 dependencies are linked to a different C library, msvcrt.dll and msvcr71.dll respectively. It is quite likely they will not work together. Lenard Bo Jangeborg wrote: I have dropped in newer versions of sdl.dll in pygame 1.7 other times and that has worked. However the new mixer that comes with 1.8 probably requires new bindings. It simply wont initiate the mixer using the latest dll (and the new extra dll's) with pygame 1.7.
Re: [pygame] vista testing...
Hello, could you also please try the different audio drivers? import os if 1: # directx os.environ['SDL_AUDIODRIVER'] = 'dsound' else: # waveout os.environ['SDL_AUDIODRIVER'] = 'waveout' cheers, On Tue, Mar 25, 2008 at 4:26 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > hrmm. > > Can you try using less channels to see if that has an effect? > > pygame.mixer.set_num_channels(4) > > > > > > On Tue, Mar 25, 2008 at 10:57 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > I have dropped in newer versions of sdl.dll in pygame 1.7 > > other times and that has worked. However the new mixer that > > comes with 1.8 probably requires new bindings. It simply wont > > initiate the mixer using the latest dll (and the new extra dll's) > > with pygame 1.7. > > > > Brian Fisher skrev: > > > > > > > When you say "that didn't work at all", what exactly do you mean? What > > > SDL prebuilts were you running with what pygame when you had a > > > problem? > > > > > > In terms of not working - do you mean you get a python exception? seg > > > fault? stuff seemed to work but no sound played? > > > > > > Also, while I haven't tried an older SDL with pygame 1.8. I've > > > successfully used the newer SDL dll's with pygame 1.7. > > > > > > So if the problems you had were trying to run the SDL from 1.7 with > > > pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL > > > dll's here: > > > http://www3.telus.net/len_l/prebuilt-msvcr71.zip > > > the result of that one test case will provide useful info on if this > > > is an SDL bug or not. > > > > > > > > > On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > > > >> Did try that yesterday but that didn't work at all. > > >> I don't think the different versions of the mixer are > > >> compatible. > > >> > > >> Brian Fisher skrev: > > >> > > >> > > >> > > >>> One other thing to try would be to swap out different SDL library > > >>> > > >> > versions. Pygame 1.8 includes newer SDL library versions than 1.7 > > >> > does, I think SDL mixer was updated as part of that. > > >> > > > >> > You should be able switch being using the dll's for 1.7 here: > > >> > http://pygame.org/ftp/win32-dependencies.zip > > >> > > > >> > and the dll's for 1.8 here: > > >> > http://www3.telus.net/len_l/prebuilt-msvcr71.zip > > >> > > > >> > just by copying the dll's over the ones in your > site-packages/pygame dir. > > >> > > > >> > so if you get scratchiness in both pygame 1.7 & 1.8 with the newer > SDL > > >> > but not with the older SDL, it would seem to be a new SDL bug. if > you > > >> > get scratchiness in pygame 1.8 with either SDL, but not in pygame > 1.7 > > >> > with either SDL, then it would seem to be something pygame > introduced. > > >> > > > >> > > > >> > On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > > >> > > > >> >> Just tried it, no differens I am afraid. One thing I noticed , and > that > > >> >> was true for > > >> >> the mingw version too, was that at 44k the music was running > > >> >> considerally slower. > > >> >> Not sure if that's any clue. > > >> >> Is the interrrupt not frequent enough for it to pump out the > music ? Or > > >> >> what do > > >> >> think is happening here. Do you have any compiler options to play > around > > >> >> with ? > > >> >> > > >> >> René Dudfield skrev: > > >> >> > > >> >> > > >> >> > > >> >>> Are you able to try the pygame from here ? > > >> >>> > > >> >> > http://thorbrian.com/pygame/builds.php > > >> >> > > > >> >> > I think this is compiled with visual C rather than mingw, so > maybe > > >> >> > it'll be different... > > >> >> > > > >> >> > cheers, > > >> >> > > > >> >> > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL > PROTECTED]> wrote: > > >> >> > > > >> >> >> The scratching are with all music files I have tested. The > music have a > > >> >> >> native sample rate > > >> >> >> of 44k so there should be no need to resample, and it does > work when the > > >> >> >> output is changed > > >> >> >> to 22k. I have tested with 15 different pieces. Furthermore > it worked ok > > >> >> >> in pygame 1.7. > > >> >> >> > > >> >> >> If I start a bit into the music I get occasional scratching > for the rest > > >> >> >> of the piece after that. > > >> >> >> > > >> >> >> Brian Fisher skrev: > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >>> The change with sample rate makes me think it may actually > have to do > > >> >> >>> > > >> >> >> > with the particular sound samples as well? I understand > that SDL is > > >> >> >> > somewhat limited on the sample rate conversions it supports > - got > > >> >> >> > particular sounds files that sound s
Re: [pygame] vista testing...
hrmm. Can you try using less channels to see if that has an effect? pygame.mixer.set_num_channels(4) On Tue, Mar 25, 2008 at 10:57 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > I have dropped in newer versions of sdl.dll in pygame 1.7 > other times and that has worked. However the new mixer that > comes with 1.8 probably requires new bindings. It simply wont > initiate the mixer using the latest dll (and the new extra dll's) > with pygame 1.7. > > Brian Fisher skrev: > > > > When you say "that didn't work at all", what exactly do you mean? What > > SDL prebuilts were you running with what pygame when you had a > > problem? > > > > In terms of not working - do you mean you get a python exception? seg > > fault? stuff seemed to work but no sound played? > > > > Also, while I haven't tried an older SDL with pygame 1.8. I've > > successfully used the newer SDL dll's with pygame 1.7. > > > > So if the problems you had were trying to run the SDL from 1.7 with > > pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL > > dll's here: > > http://www3.telus.net/len_l/prebuilt-msvcr71.zip > > the result of that one test case will provide useful info on if this > > is an SDL bug or not. > > > > > > On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > >> Did try that yesterday but that didn't work at all. > >> I don't think the different versions of the mixer are > >> compatible. > >> > >> Brian Fisher skrev: > >> > >> > >> > >>> One other thing to try would be to swap out different SDL library > >>> > >> > versions. Pygame 1.8 includes newer SDL library versions than 1.7 > >> > does, I think SDL mixer was updated as part of that. > >> > > >> > You should be able switch being using the dll's for 1.7 here: > >> > http://pygame.org/ftp/win32-dependencies.zip > >> > > >> > and the dll's for 1.8 here: > >> > http://www3.telus.net/len_l/prebuilt-msvcr71.zip > >> > > >> > just by copying the dll's over the ones in your site-packages/pygame > dir. > >> > > >> > so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL > >> > but not with the older SDL, it would seem to be a new SDL bug. if you > >> > get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7 > >> > with either SDL, then it would seem to be something pygame introduced. > >> > > >> > > >> > On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > >> > > >> >> Just tried it, no differens I am afraid. One thing I noticed , and > that > >> >> was true for > >> >> the mingw version too, was that at 44k the music was running > >> >> considerally slower. > >> >> Not sure if that's any clue. > >> >> Is the interrrupt not frequent enough for it to pump out the music ? > Or > >> >> what do > >> >> think is happening here. Do you have any compiler options to play > around > >> >> with ? > >> >> > >> >> René Dudfield skrev: > >> >> > >> >> > >> >> > >> >>> Are you able to try the pygame from here ? > >> >>> > >> >> > http://thorbrian.com/pygame/builds.php > >> >> > > >> >> > I think this is compiled with visual C rather than mingw, so maybe > >> >> > it'll be different... > >> >> > > >> >> > cheers, > >> >> > > >> >> > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > >> >> > > >> >> >> The scratching are with all music files I have tested. The music > have a > >> >> >> native sample rate > >> >> >> of 44k so there should be no need to resample, and it does work > when the > >> >> >> output is changed > >> >> >> to 22k. I have tested with 15 different pieces. Furthermore it > worked ok > >> >> >> in pygame 1.7. > >> >> >> > >> >> >> If I start a bit into the music I get occasional scratching for > the rest > >> >> >> of the piece after that. > >> >> >> > >> >> >> Brian Fisher skrev: > >> >> >> > >> >> >> > >> >> >> > >> >> >>> The change with sample rate makes me think it may actually have > to do > >> >> >>> > >> >> >> > with the particular sound samples as well? I understand that > SDL is > >> >> >> > somewhat limited on the sample rate conversions it supports - > got > >> >> >> > particular sounds files that sound scratchy you can send to > test with? > >> >> >> > > >> >> >> > also, when you say you get scratches after starting some way > into the > >> >> >> > music - do you mean you get like a pop when first playing the > music, > >> >> >> > or do you mean that you get scratches throughout the music > after you > >> >> >> > start it playing at a point in the sound? > >> >> >> > > >> >> >> > > >> >> >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL > PROTECTED]> wrote: > >> >> >> > > >> >> >> >> The buffer setting doesn't seem to make a differens. > >> >> >> >> The key seem to
Re: [pygame] vista testing...
Hi! I am not sure if this is related because I do not get any scratching on my sounds when I only use pygame.init with no mixer init but the attached file, the only one of the bunch I have will not play at all. In fact it says error, no src. Also it says it is a null file. It is an 8 bit, 88K but I have many like this one but they play with no problems or scratching. I use both 8 bit and 16 bit and one is played continuously, but this one dies once assigned with the null, no src error. So, what is the difference in this file from all others when trying to play it with the mixer? You have to convert it back to a .wav file for the list rejected with the extension on it, so I sent it without it. I am using pygame 1.8 rc 3 and SDL (1,2,12) Bruce When you say "that didn't work at all", what exactly do you mean? What SDL prebuilts were you running with what pygame when you had a problem? In terms of not working - do you mean you get a python exception? seg fault? stuff seemed to work but no sound played? Also, while I haven't tried an older SDL with pygame 1.8. I've successfully used the newer SDL dll's with pygame 1.7. So if the problems you had were trying to run the SDL from 1.7 with pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL dll's here: http://www3.telus.net/len_l/prebuilt-msvcr71.zip the result of that one test case will provide useful info on if this is an SDL bug or not. On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > Did try that yesterday but that didn't work at all. > I don't think the different versions of the mixer are > compatible. > > Brian Fisher skrev: > > > > One other thing to try would be to swap out different SDL library > > versions. Pygame 1.8 includes newer SDL library versions than 1.7 > > does, I think SDL mixer was updated as part of that. > > > > You should be able switch being using the dll's for 1.7 here: > > http://pygame.org/ftp/win32-dependencies.zip > > > > and the dll's for 1.8 here: > > http://www3.telus.net/len_l/prebuilt-msvcr71.zip > > > > just by copying the dll's over the ones in your site-packages/pygame dir. > > > > so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL > > but not with the older SDL, it would seem to be a new SDL bug. if you > > get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7 > > with either SDL, then it would seem to be something pygame introduced. > > > > > > On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > >> Just tried it, no differens I am afraid. One thing I noticed , and that > >> was true for > >> the mingw version too, was that at 44k the music was running > >> considerally slower. > >> Not sure if that's any clue. > >> Is the interrrupt not frequent enough for it to pump out the music ? Or > >> what do > >> think is happening here. Do you have any compiler options to play around > >> with ? > >> > >> René Dudfield skrev: > >> > >> > >> > >>> Are you able to try the pygame from here ? > >>> > >> > http://thorbrian.com/pygame/builds.php > >> > > >> > I think this is compiled with visual C rather than mingw, so maybe > >> > it'll be different... > >> > > >> > cheers, > >> > > >> > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> > > >> >> The scratching are with all music files I have tested. The music have a > >> >> native sample rate > >> >> of 44k so there should be no need to resample, and it does work when the > >> >> output is changed > >> >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok > >> >> in pygame 1.7. > >> >> > >> >> If I start a bit into the music I get occasional scratching for the rest > >> >> of the piece after that. > >> >> > >> >> Brian Fisher skrev: > >> >> > >> >> > >> >> > >> >>> The change with sample rate makes me think it may actually have to do > >> >>> > >> >> > with the particular sound samples as well? I understand that SDL is > >> >> > somewhat limited on the sample rate conversions it supports - got > >> >> > particular sounds files that sound scratchy you can send to test with? > >> >> > > >> >> > also, when you say you get scratches after starting some way into the > >> >> > music - do you mean you get like a pop when first playing the music, > >> >> > or do you mean that you get scratches throughout the music after you > >> >> > start it playing at a point in the sound? > >> >> > > >> >> > > >> >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> >> > > >> >> >> The buffer setting doesn't seem to make a differens. > >> >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound > >> >> >> but OK at 22k. But even then I get scratches if I start some way into > >> >> >> the music > >> >> >> rather then a
Re: [pygame] vista testing...
I have dropped in newer versions of sdl.dll in pygame 1.7 other times and that has worked. However the new mixer that comes with 1.8 probably requires new bindings. It simply wont initiate the mixer using the latest dll (and the new extra dll's) with pygame 1.7. Brian Fisher skrev: When you say "that didn't work at all", what exactly do you mean? What SDL prebuilts were you running with what pygame when you had a problem? In terms of not working - do you mean you get a python exception? seg fault? stuff seemed to work but no sound played? Also, while I haven't tried an older SDL with pygame 1.8. I've successfully used the newer SDL dll's with pygame 1.7. So if the problems you had were trying to run the SDL from 1.7 with pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL dll's here: http://www3.telus.net/len_l/prebuilt-msvcr71.zip the result of that one test case will provide useful info on if this is an SDL bug or not. On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: Did try that yesterday but that didn't work at all. I don't think the different versions of the mixer are compatible. Brian Fisher skrev: One other thing to try would be to swap out different SDL library > versions. Pygame 1.8 includes newer SDL library versions than 1.7 > does, I think SDL mixer was updated as part of that. > > You should be able switch being using the dll's for 1.7 here: > http://pygame.org/ftp/win32-dependencies.zip > > and the dll's for 1.8 here: > http://www3.telus.net/len_l/prebuilt-msvcr71.zip > > just by copying the dll's over the ones in your site-packages/pygame dir. > > so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL > but not with the older SDL, it would seem to be a new SDL bug. if you > get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7 > with either SDL, then it would seem to be something pygame introduced. > > > On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> Just tried it, no differens I am afraid. One thing I noticed , and that >> was true for >> the mingw version too, was that at 44k the music was running >> considerally slower. >> Not sure if that's any clue. >> Is the interrrupt not frequent enough for it to pump out the music ? Or >> what do >> think is happening here. Do you have any compiler options to play around >> with ? >> >> René Dudfield skrev: >> >> >> >>> Are you able to try the pygame from here ? >>> >> > http://thorbrian.com/pygame/builds.php >> > >> > I think this is compiled with visual C rather than mingw, so maybe >> > it'll be different... >> > >> > cheers, >> > >> > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> > >> >> The scratching are with all music files I have tested. The music have a >> >> native sample rate >> >> of 44k so there should be no need to resample, and it does work when the >> >> output is changed >> >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok >> >> in pygame 1.7. >> >> >> >> If I start a bit into the music I get occasional scratching for the rest >> >> of the piece after that. >> >> >> >> Brian Fisher skrev: >> >> >> >> >> >> >> >>> The change with sample rate makes me think it may actually have to do >> >>> >> >> > with the particular sound samples as well? I understand that SDL is >> >> > somewhat limited on the sample rate conversions it supports - got >> >> > particular sounds files that sound scratchy you can send to test with? >> >> > >> >> > also, when you say you get scratches after starting some way into the >> >> > music - do you mean you get like a pop when first playing the music, >> >> > or do you mean that you get scratches throughout the music after you >> >> > start it playing at a point in the sound? >> >> > >> >> > >> >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> >> > >> >> >> The buffer setting doesn't seem to make a differens. >> >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound >> >> >> but OK at 22k. But even then I get scratches if I start some way into >> >> >> the music >> >> >> rather then at the start. The later problem I had in pygame 1.7 too. >> >> >> >> >> >> In pygame 1.7 music worked OK in Vista at 44k. >> >> >> I have tried both ogg and mp3 in pygame 1.8. >> >> >> Have you tried playing music at 44k on XP machines? Maybe this is a more >> >> >> general problem. >> >> >> >> >> >> Another thing that seem to have changed is that if a path to a sound file >> >> >> is wrong it doesn't cause an exception. Instead it returns an empty >> >> >> sound object.. >> >> >> Is that really intended ? >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> >> >> > >> > >>
Re: [pygame] vista testing...
When you say "that didn't work at all", what exactly do you mean? What SDL prebuilts were you running with what pygame when you had a problem? In terms of not working - do you mean you get a python exception? seg fault? stuff seemed to work but no sound played? Also, while I haven't tried an older SDL with pygame 1.8. I've successfully used the newer SDL dll's with pygame 1.7. So if the problems you had were trying to run the SDL from 1.7 with pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL dll's here: http://www3.telus.net/len_l/prebuilt-msvcr71.zip the result of that one test case will provide useful info on if this is an SDL bug or not. On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > Did try that yesterday but that didn't work at all. > I don't think the different versions of the mixer are > compatible. > > Brian Fisher skrev: > > > > One other thing to try would be to swap out different SDL library > > versions. Pygame 1.8 includes newer SDL library versions than 1.7 > > does, I think SDL mixer was updated as part of that. > > > > You should be able switch being using the dll's for 1.7 here: > > http://pygame.org/ftp/win32-dependencies.zip > > > > and the dll's for 1.8 here: > > http://www3.telus.net/len_l/prebuilt-msvcr71.zip > > > > just by copying the dll's over the ones in your site-packages/pygame dir. > > > > so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL > > but not with the older SDL, it would seem to be a new SDL bug. if you > > get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7 > > with either SDL, then it would seem to be something pygame introduced. > > > > > > On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > >> Just tried it, no differens I am afraid. One thing I noticed , and that > >> was true for > >> the mingw version too, was that at 44k the music was running > >> considerally slower. > >> Not sure if that's any clue. > >> Is the interrrupt not frequent enough for it to pump out the music ? Or > >> what do > >> think is happening here. Do you have any compiler options to play around > >> with ? > >> > >> René Dudfield skrev: > >> > >> > >> > >>> Are you able to try the pygame from here ? > >>> > >> > http://thorbrian.com/pygame/builds.php > >> > > >> > I think this is compiled with visual C rather than mingw, so maybe > >> > it'll be different... > >> > > >> > cheers, > >> > > >> > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > >> > > >> >> The scratching are with all music files I have tested. The music have > a > >> >> native sample rate > >> >> of 44k so there should be no need to resample, and it does work when > the > >> >> output is changed > >> >> to 22k. I have tested with 15 different pieces. Furthermore it > worked ok > >> >> in pygame 1.7. > >> >> > >> >> If I start a bit into the music I get occasional scratching for the > rest > >> >> of the piece after that. > >> >> > >> >> Brian Fisher skrev: > >> >> > >> >> > >> >> > >> >>> The change with sample rate makes me think it may actually have to do > >> >>> > >> >> > with the particular sound samples as well? I understand that SDL is > >> >> > somewhat limited on the sample rate conversions it supports - got > >> >> > particular sounds files that sound scratchy you can send to test > with? > >> >> > > >> >> > also, when you say you get scratches after starting some way into > the > >> >> > music - do you mean you get like a pop when first playing the > music, > >> >> > or do you mean that you get scratches throughout the music after > you > >> >> > start it playing at a point in the sound? > >> >> > > >> >> > > >> >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > >> >> > > >> >> >> The buffer setting doesn't seem to make a differens. > >> >> >> The key seem to be the sampling rate. Lots of scratching at 44k > sound > >> >> >> but OK at 22k. But even then I get scratches if I start some way > into > >> >> >> the music > >> >> >> rather then at the start. The later problem I had in pygame 1.7 > too. > >> >> >> > >> >> >> In pygame 1.7 music worked OK in Vista at 44k. > >> >> >> I have tried both ogg and mp3 in pygame 1.8. > >> >> >> Have you tried playing music at 44k on XP machines? Maybe this > is a more > >> >> >> general problem. > >> >> >> > >> >> >> Another thing that seem to have changed is that if a path to a > sound file > >> >> >> is wrong it doesn't cause an exception. Instead it returns an > empty > >> >> >> sound object.. > >> >> >> Is that really intended ? > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> > > >> > > >> > >> > >> > > > > > >
Re: [pygame] vista testing...
Tried running the music on my XP machine, but got the same problem there. Won't work on 44k but is ok on 22k. That machine has DMA active on the IDE device René Dudfield skrev: ah, ok. hrmm. Are you able to check to see if dma is enabled on your hard drive? http://www.onthegosoft.com/dma_setting_nt.htm I'll have more of a look at the sound code in the mean time. On Tue, Mar 25, 2008 at 8:20 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: Just tried it, no differens I am afraid. One thing I noticed , and that was true for the mingw version too, was that at 44k the music was running considerally slower. Not sure if that's any clue. Is the interrrupt not frequent enough for it to pump out the music ? Or what do think is happening here. Do you have any compiler options to play around with ? René Dudfield skrev: Are you able to try the pygame from here ? > http://thorbrian.com/pygame/builds.php > > I think this is compiled with visual C rather than mingw, so maybe > it'll be different... > > cheers, > > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> The scratching are with all music files I have tested. The music have a >> native sample rate >> of 44k so there should be no need to resample, and it does work when the >> output is changed >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok >> in pygame 1.7. >> >> If I start a bit into the music I get occasional scratching for the rest >> of the piece after that. >> >> Brian Fisher skrev: >> >> >> >>> The change with sample rate makes me think it may actually have to do >>> >> > with the particular sound samples as well? I understand that SDL is >> > somewhat limited on the sample rate conversions it supports - got >> > particular sounds files that sound scratchy you can send to test with? >> > >> > also, when you say you get scratches after starting some way into the >> > music - do you mean you get like a pop when first playing the music, >> > or do you mean that you get scratches throughout the music after you >> > start it playing at a point in the sound? >> > >> > >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> > >> >> The buffer setting doesn't seem to make a differens. >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound >> >> but OK at 22k. But even then I get scratches if I start some way into >> >> the music >> >> rather then at the start. The later problem I had in pygame 1.7 too. >> >> >> >> In pygame 1.7 music worked OK in Vista at 44k. >> >> I have tried both ogg and mp3 in pygame 1.8. >> >> Have you tried playing music at 44k on XP machines? Maybe this is a more >> >> general problem. >> >> >> >> Another thing that seem to have changed is that if a path to a sound file >> >> is wrong it doesn't cause an exception. Instead it returns an empty >> >> sound object.. >> >> Is that really intended ? >> >> >> >> >> > >> > >> >> >> > >
Re: [pygame] vista testing...
Did try that yesterday but that didn't work at all. I don't think the different versions of the mixer are compatible. Brian Fisher skrev: One other thing to try would be to swap out different SDL library versions. Pygame 1.8 includes newer SDL library versions than 1.7 does, I think SDL mixer was updated as part of that. You should be able switch being using the dll's for 1.7 here: http://pygame.org/ftp/win32-dependencies.zip and the dll's for 1.8 here: http://www3.telus.net/len_l/prebuilt-msvcr71.zip just by copying the dll's over the ones in your site-packages/pygame dir. so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL but not with the older SDL, it would seem to be a new SDL bug. if you get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7 with either SDL, then it would seem to be something pygame introduced. On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: Just tried it, no differens I am afraid. One thing I noticed , and that was true for the mingw version too, was that at 44k the music was running considerally slower. Not sure if that's any clue. Is the interrrupt not frequent enough for it to pump out the music ? Or what do think is happening here. Do you have any compiler options to play around with ? René Dudfield skrev: Are you able to try the pygame from here ? > http://thorbrian.com/pygame/builds.php > > I think this is compiled with visual C rather than mingw, so maybe > it'll be different... > > cheers, > > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> The scratching are with all music files I have tested. The music have a >> native sample rate >> of 44k so there should be no need to resample, and it does work when the >> output is changed >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok >> in pygame 1.7. >> >> If I start a bit into the music I get occasional scratching for the rest >> of the piece after that. >> >> Brian Fisher skrev: >> >> >> >>> The change with sample rate makes me think it may actually have to do >>> >> > with the particular sound samples as well? I understand that SDL is >> > somewhat limited on the sample rate conversions it supports - got >> > particular sounds files that sound scratchy you can send to test with? >> > >> > also, when you say you get scratches after starting some way into the >> > music - do you mean you get like a pop when first playing the music, >> > or do you mean that you get scratches throughout the music after you >> > start it playing at a point in the sound? >> > >> > >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> > >> >> The buffer setting doesn't seem to make a differens. >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound >> >> but OK at 22k. But even then I get scratches if I start some way into >> >> the music >> >> rather then at the start. The later problem I had in pygame 1.7 too. >> >> >> >> In pygame 1.7 music worked OK in Vista at 44k. >> >> I have tried both ogg and mp3 in pygame 1.8. >> >> Have you tried playing music at 44k on XP machines? Maybe this is a more >> >> general problem. >> >> >> >> Another thing that seem to have changed is that if a path to a sound file >> >> is wrong it doesn't cause an exception. Instead it returns an empty >> >> sound object.. >> >> Is that really intended ? >> >> >> >> >> > >> > >> >> >> > >
Re: [pygame] vista testing...
Its the same with mixer.sound. Even 8k sampled soundeffects gets distorted when the output is 44k. Brian Fisher skrev: is this mixer.music or mixer.Sound/Channel that you are getting scratchiness with? On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: Just tried it, no differens I am afraid. One thing I noticed , and that was true for the mingw version too, was that at 44k the music was running considerally slower. Not sure if that's any clue. Is the interrrupt not frequent enough for it to pump out the music ? Or what do think is happening here. Do you have any compiler options to play around with ? René Dudfield skrev: Are you able to try the pygame from here ? > http://thorbrian.com/pygame/builds.php > > I think this is compiled with visual C rather than mingw, so maybe > it'll be different... > > cheers, > > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> The scratching are with all music files I have tested. The music have a >> native sample rate >> of 44k so there should be no need to resample, and it does work when the >> output is changed >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok >> in pygame 1.7. >> >> If I start a bit into the music I get occasional scratching for the rest >> of the piece after that. >> >> Brian Fisher skrev: >> >> >> >>> The change with sample rate makes me think it may actually have to do >>> >> > with the particular sound samples as well? I understand that SDL is >> > somewhat limited on the sample rate conversions it supports - got >> > particular sounds files that sound scratchy you can send to test with? >> > >> > also, when you say you get scratches after starting some way into the >> > music - do you mean you get like a pop when first playing the music, >> > or do you mean that you get scratches throughout the music after you >> > start it playing at a point in the sound? >> > >> > >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> > >> >> The buffer setting doesn't seem to make a differens. >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound >> >> but OK at 22k. But even then I get scratches if I start some way into >> >> the music >> >> rather then at the start. The later problem I had in pygame 1.7 too. >> >> >> >> In pygame 1.7 music worked OK in Vista at 44k. >> >> I have tried both ogg and mp3 in pygame 1.8. >> >> Have you tried playing music at 44k on XP machines? Maybe this is a more >> >> general problem. >> >> >> >> Another thing that seem to have changed is that if a path to a sound file >> >> is wrong it doesn't cause an exception. Instead it returns an empty >> >> sound object.. >> >> Is that really intended ? >> >> >> >> >> > >> > >> >> >> > >
Re: [pygame] vista testing...
One other thing to try would be to swap out different SDL library versions. Pygame 1.8 includes newer SDL library versions than 1.7 does, I think SDL mixer was updated as part of that. You should be able switch being using the dll's for 1.7 here: http://pygame.org/ftp/win32-dependencies.zip and the dll's for 1.8 here: http://www3.telus.net/len_l/prebuilt-msvcr71.zip just by copying the dll's over the ones in your site-packages/pygame dir. so if you get scratchiness in both pygame 1.7 & 1.8 with the newer SDL but not with the older SDL, it would seem to be a new SDL bug. if you get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7 with either SDL, then it would seem to be something pygame introduced. On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > Just tried it, no differens I am afraid. One thing I noticed , and that > was true for > the mingw version too, was that at 44k the music was running > considerally slower. > Not sure if that's any clue. > Is the interrrupt not frequent enough for it to pump out the music ? Or > what do > think is happening here. Do you have any compiler options to play around > with ? > > René Dudfield skrev: > > > > Are you able to try the pygame from here ? > > http://thorbrian.com/pygame/builds.php > > > > I think this is compiled with visual C rather than mingw, so maybe > > it'll be different... > > > > cheers, > > > > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > >> The scratching are with all music files I have tested. The music have a > >> native sample rate > >> of 44k so there should be no need to resample, and it does work when the > >> output is changed > >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok > >> in pygame 1.7. > >> > >> If I start a bit into the music I get occasional scratching for the rest > >> of the piece after that. > >> > >> Brian Fisher skrev: > >> > >> > >> > >>> The change with sample rate makes me think it may actually have to do > >>> > >> > with the particular sound samples as well? I understand that SDL is > >> > somewhat limited on the sample rate conversions it supports - got > >> > particular sounds files that sound scratchy you can send to test with? > >> > > >> > also, when you say you get scratches after starting some way into the > >> > music - do you mean you get like a pop when first playing the music, > >> > or do you mean that you get scratches throughout the music after you > >> > start it playing at a point in the sound? > >> > > >> > > >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > >> > > >> >> The buffer setting doesn't seem to make a differens. > >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound > >> >> but OK at 22k. But even then I get scratches if I start some way into > >> >> the music > >> >> rather then at the start. The later problem I had in pygame 1.7 too. > >> >> > >> >> In pygame 1.7 music worked OK in Vista at 44k. > >> >> I have tried both ogg and mp3 in pygame 1.8. > >> >> Have you tried playing music at 44k on XP machines? Maybe this is a > more > >> >> general problem. > >> >> > >> >> Another thing that seem to have changed is that if a path to a sound > file > >> >> is wrong it doesn't cause an exception. Instead it returns an empty > >> >> sound object.. > >> >> Is that really intended ? > >> >> > >> >> > >> > > >> > > >> > >> > >> > > > > > >
Re: [pygame] vista testing...
I have two SATA drives, not sure if there is a DMA setting for those, can't find any at any rate. I also have an external drive running over USB2 and I get the same effect there. René Dudfield skrev: ah, ok. hrmm. Are you able to check to see if dma is enabled on your hard drive? http://www.onthegosoft.com/dma_setting_nt.htm I'll have more of a look at the sound code in the mean time. On Tue, Mar 25, 2008 at 8:20 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: Just tried it, no differens I am afraid. One thing I noticed , and that was true for the mingw version too, was that at 44k the music was running considerally slower. Not sure if that's any clue. Is the interrrupt not frequent enough for it to pump out the music ? Or what do think is happening here. Do you have any compiler options to play around with ? René Dudfield skrev: Are you able to try the pygame from here ? > http://thorbrian.com/pygame/builds.php > > I think this is compiled with visual C rather than mingw, so maybe > it'll be different... > > cheers, > > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> The scratching are with all music files I have tested. The music have a >> native sample rate >> of 44k so there should be no need to resample, and it does work when the >> output is changed >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok >> in pygame 1.7. >> >> If I start a bit into the music I get occasional scratching for the rest >> of the piece after that. >> >> Brian Fisher skrev: >> >> >> >>> The change with sample rate makes me think it may actually have to do >>> >> > with the particular sound samples as well? I understand that SDL is >> > somewhat limited on the sample rate conversions it supports - got >> > particular sounds files that sound scratchy you can send to test with? >> > >> > also, when you say you get scratches after starting some way into the >> > music - do you mean you get like a pop when first playing the music, >> > or do you mean that you get scratches throughout the music after you >> > start it playing at a point in the sound? >> > >> > >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> > >> >> The buffer setting doesn't seem to make a differens. >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound >> >> but OK at 22k. But even then I get scratches if I start some way into >> >> the music >> >> rather then at the start. The later problem I had in pygame 1.7 too. >> >> >> >> In pygame 1.7 music worked OK in Vista at 44k. >> >> I have tried both ogg and mp3 in pygame 1.8. >> >> Have you tried playing music at 44k on XP machines? Maybe this is a more >> >> general problem. >> >> >> >> Another thing that seem to have changed is that if a path to a sound file >> >> is wrong it doesn't cause an exception. Instead it returns an empty >> >> sound object.. >> >> Is that really intended ? >> >> >> >> >> > >> > >> >> >> > >
Re: [pygame] vista testing...
Hi! It will send the music out slower if you have increased the buffer size. Not at a slwoer speed entirely, just starting the music slower, more of a pause before starting. Bruce Just tried it, no differens I am afraid. One thing I noticed , and that was true for the mingw version too, was that at 44k the music was running considerally slower. Not sure if that's any clue. Is the interrrupt not frequent enough for it to pump out the music ? Or what do think is happening here. Do you have any compiler options to play around with ? René Dudfield skrev: > Are you able to try the pygame from here ? > http://thorbrian.com/pygame/builds.php > > I think this is compiled with visual C rather than mingw, so maybe > it'll be different... > > cheers, > > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> The scratching are with all music files I have tested. The music have a >> native sample rate >> of 44k so there should be no need to resample, and it does work when the >> output is changed >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok >> in pygame 1.7. >> >> If I start a bit into the music I get occasional scratching for the rest >> of the piece after that. >> >> Brian Fisher skrev: >> >> >> >>> The change with sample rate makes me think it may actually have to do >>> >> > with the particular sound samples as well? I understand that SDL is >> > somewhat limited on the sample rate conversions it supports - got >> > particular sounds files that sound scratchy you can send to test with? >> > >> > also, when you say you get scratches after starting some way into the >> > music - do you mean you get like a pop when first playing the music, >> > or do you mean that you get scratches throughout the music after you >> > start it playing at a point in the sound? >> > >> > >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> > >> >> The buffer setting doesn't seem to make a differens. >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound >> >> but OK at 22k. But even then I get scratches if I start some way into >> >> the music >> >> rather then at the start. The later problem I had in pygame 1.7 too. >> >> >> >> In pygame 1.7 music worked OK in Vista at 44k. >> >> I have tried both ogg and mp3 in pygame 1.8. >> >> Have you tried playing music at 44k on XP machines? Maybe this is a more >> >> general problem. >> >> >> >> Another thing that seem to have changed is that if a path to a sound file >> >> is wrong it doesn't cause an exception. Instead it returns an empty >> >> sound object.. >> >> Is that really intended ? >> >> >> >> >> > >> > >> >> >> > > -- No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.21.8/1340 - Release Date: 3/23/2008 6:50 PM
Re: [pygame] vista testing...
is this mixer.music or mixer.Sound/Channel that you are getting scratchiness with? On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > Just tried it, no differens I am afraid. One thing I noticed , and that > was true for > the mingw version too, was that at 44k the music was running > considerally slower. > Not sure if that's any clue. > Is the interrrupt not frequent enough for it to pump out the music ? Or > what do > think is happening here. Do you have any compiler options to play around > with ? > > René Dudfield skrev: > > > > Are you able to try the pygame from here ? > > http://thorbrian.com/pygame/builds.php > > > > I think this is compiled with visual C rather than mingw, so maybe > > it'll be different... > > > > cheers, > > > > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > >> The scratching are with all music files I have tested. The music have a > >> native sample rate > >> of 44k so there should be no need to resample, and it does work when the > >> output is changed > >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok > >> in pygame 1.7. > >> > >> If I start a bit into the music I get occasional scratching for the rest > >> of the piece after that. > >> > >> Brian Fisher skrev: > >> > >> > >> > >>> The change with sample rate makes me think it may actually have to do > >>> > >> > with the particular sound samples as well? I understand that SDL is > >> > somewhat limited on the sample rate conversions it supports - got > >> > particular sounds files that sound scratchy you can send to test with? > >> > > >> > also, when you say you get scratches after starting some way into the > >> > music - do you mean you get like a pop when first playing the music, > >> > or do you mean that you get scratches throughout the music after you > >> > start it playing at a point in the sound? > >> > > >> > > >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > >> > > >> >> The buffer setting doesn't seem to make a differens. > >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound > >> >> but OK at 22k. But even then I get scratches if I start some way into > >> >> the music > >> >> rather then at the start. The later problem I had in pygame 1.7 too. > >> >> > >> >> In pygame 1.7 music worked OK in Vista at 44k. > >> >> I have tried both ogg and mp3 in pygame 1.8. > >> >> Have you tried playing music at 44k on XP machines? Maybe this is a > more > >> >> general problem. > >> >> > >> >> Another thing that seem to have changed is that if a path to a sound > file > >> >> is wrong it doesn't cause an exception. Instead it returns an empty > >> >> sound object.. > >> >> Is that really intended ? > >> >> > >> >> > >> > > >> > > >> > >> > >> > > > > > >
Re: [pygame] vista testing...
ah, ok. hrmm. Are you able to check to see if dma is enabled on your hard drive? http://www.onthegosoft.com/dma_setting_nt.htm I'll have more of a look at the sound code in the mean time. On Tue, Mar 25, 2008 at 8:20 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > Just tried it, no differens I am afraid. One thing I noticed , and that > was true for > the mingw version too, was that at 44k the music was running > considerally slower. > Not sure if that's any clue. > Is the interrrupt not frequent enough for it to pump out the music ? Or > what do > think is happening here. Do you have any compiler options to play around > with ? > > René Dudfield skrev: > > > > Are you able to try the pygame from here ? > > http://thorbrian.com/pygame/builds.php > > > > I think this is compiled with visual C rather than mingw, so maybe > > it'll be different... > > > > cheers, > > > > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > >> The scratching are with all music files I have tested. The music have a > >> native sample rate > >> of 44k so there should be no need to resample, and it does work when the > >> output is changed > >> to 22k. I have tested with 15 different pieces. Furthermore it worked ok > >> in pygame 1.7. > >> > >> If I start a bit into the music I get occasional scratching for the rest > >> of the piece after that. > >> > >> Brian Fisher skrev: > >> > >> > >> > >>> The change with sample rate makes me think it may actually have to do > >>> > >> > with the particular sound samples as well? I understand that SDL is > >> > somewhat limited on the sample rate conversions it supports - got > >> > particular sounds files that sound scratchy you can send to test with? > >> > > >> > also, when you say you get scratches after starting some way into the > >> > music - do you mean you get like a pop when first playing the music, > >> > or do you mean that you get scratches throughout the music after you > >> > start it playing at a point in the sound? > >> > > >> > > >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > >> > > >> >> The buffer setting doesn't seem to make a differens. > >> >> The key seem to be the sampling rate. Lots of scratching at 44k sound > >> >> but OK at 22k. But even then I get scratches if I start some way into > >> >> the music > >> >> rather then at the start. The later problem I had in pygame 1.7 too. > >> >> > >> >> In pygame 1.7 music worked OK in Vista at 44k. > >> >> I have tried both ogg and mp3 in pygame 1.8. > >> >> Have you tried playing music at 44k on XP machines? Maybe this is a > more > >> >> general problem. > >> >> > >> >> Another thing that seem to have changed is that if a path to a sound > file > >> >> is wrong it doesn't cause an exception. Instead it returns an empty > >> >> sound object.. > >> >> Is that really intended ? > >> >> > >> >> > >> > > >> > > >> > >> > >> > > > > > >
Re: [pygame] vista testing...
Just tried it, no differens I am afraid. One thing I noticed , and that was true for the mingw version too, was that at 44k the music was running considerally slower. Not sure if that's any clue. Is the interrrupt not frequent enough for it to pump out the music ? Or what do think is happening here. Do you have any compiler options to play around with ? René Dudfield skrev: Are you able to try the pygame from here ? http://thorbrian.com/pygame/builds.php I think this is compiled with visual C rather than mingw, so maybe it'll be different... cheers, On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: The scratching are with all music files I have tested. The music have a native sample rate of 44k so there should be no need to resample, and it does work when the output is changed to 22k. I have tested with 15 different pieces. Furthermore it worked ok in pygame 1.7. If I start a bit into the music I get occasional scratching for the rest of the piece after that. Brian Fisher skrev: The change with sample rate makes me think it may actually have to do > with the particular sound samples as well? I understand that SDL is > somewhat limited on the sample rate conversions it supports - got > particular sounds files that sound scratchy you can send to test with? > > also, when you say you get scratches after starting some way into the > music - do you mean you get like a pop when first playing the music, > or do you mean that you get scratches throughout the music after you > start it playing at a point in the sound? > > > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> The buffer setting doesn't seem to make a differens. >> The key seem to be the sampling rate. Lots of scratching at 44k sound >> but OK at 22k. But even then I get scratches if I start some way into >> the music >> rather then at the start. The later problem I had in pygame 1.7 too. >> >> In pygame 1.7 music worked OK in Vista at 44k. >> I have tried both ogg and mp3 in pygame 1.8. >> Have you tried playing music at 44k on XP machines? Maybe this is a more >> general problem. >> >> Another thing that seem to have changed is that if a path to a sound file >> is wrong it doesn't cause an exception. Instead it returns an empty >> sound object.. >> Is that really intended ? >> >> > >
Re: [pygame] vista testing...
Are you able to try the pygame from here ? http://thorbrian.com/pygame/builds.php I think this is compiled with visual C rather than mingw, so maybe it'll be different... cheers, On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > The scratching are with all music files I have tested. The music have a > native sample rate > of 44k so there should be no need to resample, and it does work when the > output is changed > to 22k. I have tested with 15 different pieces. Furthermore it worked ok > in pygame 1.7. > > If I start a bit into the music I get occasional scratching for the rest > of the piece after that. > > Brian Fisher skrev: > > > > The change with sample rate makes me think it may actually have to do > > with the particular sound samples as well? I understand that SDL is > > somewhat limited on the sample rate conversions it supports - got > > particular sounds files that sound scratchy you can send to test with? > > > > also, when you say you get scratches after starting some way into the > > music - do you mean you get like a pop when first playing the music, > > or do you mean that you get scratches throughout the music after you > > start it playing at a point in the sound? > > > > > > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > >> The buffer setting doesn't seem to make a differens. > >> The key seem to be the sampling rate. Lots of scratching at 44k sound > >> but OK at 22k. But even then I get scratches if I start some way into > >> the music > >> rather then at the start. The later problem I had in pygame 1.7 too. > >> > >> In pygame 1.7 music worked OK in Vista at 44k. > >> I have tried both ogg and mp3 in pygame 1.8. > >> Have you tried playing music at 44k on XP machines? Maybe this is a more > >> general problem. > >> > >> Another thing that seem to have changed is that if a path to a sound file > >> is wrong it doesn't cause an exception. Instead it returns an empty > >> sound object.. > >> Is that really intended ? > >> > >> > > > > > >
Re: [pygame] vista testing...
The scratching are with all music files I have tested. The music have a native sample rate of 44k so there should be no need to resample, and it does work when the output is changed to 22k. I have tested with 15 different pieces. Furthermore it worked ok in pygame 1.7. If I start a bit into the music I get occasional scratching for the rest of the piece after that. Brian Fisher skrev: The change with sample rate makes me think it may actually have to do with the particular sound samples as well? I understand that SDL is somewhat limited on the sample rate conversions it supports - got particular sounds files that sound scratchy you can send to test with? also, when you say you get scratches after starting some way into the music - do you mean you get like a pop when first playing the music, or do you mean that you get scratches throughout the music after you start it playing at a point in the sound? On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: The buffer setting doesn't seem to make a differens. The key seem to be the sampling rate. Lots of scratching at 44k sound but OK at 22k. But even then I get scratches if I start some way into the music rather then at the start. The later problem I had in pygame 1.7 too. In pygame 1.7 music worked OK in Vista at 44k. I have tried both ogg and mp3 in pygame 1.8. Have you tried playing music at 44k on XP machines? Maybe this is a more general problem. Another thing that seem to have changed is that if a path to a sound file is wrong it doesn't cause an exception. Instead it returns an empty sound object.. Is that really intended ?
Re: [pygame] vista testing...
The change with sample rate makes me think it may actually have to do with the particular sound samples as well? I understand that SDL is somewhat limited on the sample rate conversions it supports - got particular sounds files that sound scratchy you can send to test with? also, when you say you get scratches after starting some way into the music - do you mean you get like a pop when first playing the music, or do you mean that you get scratches throughout the music after you start it playing at a point in the sound? On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > The buffer setting doesn't seem to make a differens. > The key seem to be the sampling rate. Lots of scratching at 44k sound > but OK at 22k. But even then I get scratches if I start some way into > the music > rather then at the start. The later problem I had in pygame 1.7 too. > > In pygame 1.7 music worked OK in Vista at 44k. > I have tried both ogg and mp3 in pygame 1.8. > Have you tried playing music at 44k on XP machines? Maybe this is a more > general problem. > > Another thing that seem to have changed is that if a path to a sound file > is wrong it doesn't cause an exception. Instead it returns an empty > sound object.. > Is that really intended ? >
Re: [pygame] vista testing...
Well as I said earlier I am using a Soundblaster X-Fi card, I even inactivated the driver to the internal card on the motherboard to be on the safe side. I'll try and test on some other machines too. René Dudfield skrev: ok, thanks. Yeah. The problem only seems to happen with some machines. I think it's related to certain inbuilt sound cards. On Mon, Mar 24, 2008 at 10:31 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: Did try * 6, now I even tried 1024*9, still sounds awful. Have you tested 44k output on XP ? René Dudfield skrev: Thanks for your testing Bo. > > I guess if you used 1024 * 3 * 2 for 44K sound then it wouldn't be > scratchy too. This is because you need twice the buffer size to avoid > scratchyness as compared to 22K sound - which is half the size of the > 44K sound. > > Thanks for the tip about the Sound object not raising an exception. > I'll add a few more unit tests for the sound stuff. > > > cheers, > > > On Mon, Mar 24, 2008 at 8:27 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> The buffer setting doesn't seem to make a differens. >> The key seem to be the sampling rate. Lots of scratching at 44k sound >> but OK at 22k. But even then I get scratches if I start some way into >> the music >> rather then at the start. The later problem I had in pygame 1.7 too. >> >> In pygame 1.7 music worked OK in Vista at 44k. >> I have tried both ogg and mp3 in pygame 1.8. >> Have you tried playing music at 44k on XP machines? Maybe this is a more >> general problem. >> >> Another thing that seem to have changed is that if a path to a sound file >> is wrong it doesn't cause an exception. Instead it returns an empty >> sound object.. >> Is that really intended ? >> >> >> >> René Dudfield skrev: >> >> >> >>> yeah, I think generally increasing the buffer size helps people. >>> >> > >> > For rc5 I increased the default buffer size to 1024 * 3... which has >> > worked in the past to fix things up on most peoples computers. >> > >> > Unfortunately increasing it over 3*1024 starts to make the sound lag >> > noticable... at least to me. So I think it will have to be a per >> > game, or per user setting until it gets fixed propperly. >> > >> > >> > If someone could lodge a bug report at: >> > http://bugzilla.libsdl.org/ >> > >> > That would be greatly appreciated. >> > >> > I think it's best to fix this properly in SDL_mixer... but for now the >> > work around is to increase the default buffer size on a per computer >> > basis. >> > >> > cheers, >> > >> > >> > >> > On Sun, Mar 23, 2008 at 8:54 AM, FT <[EMAIL PROTECTED]> wrote: >> > >> >> Hi! >> >> >> >> I think there was also an issue of pre-init for any init would wipe out >> >> any settings. So the pre-init was setup to prevent the loss of any settings >> >> besides the size of the buffer to hold the data. The issue comes up all the >> >> time and is in the specs on the mixer and sound. Where it recommends >> >> increasing the buffer size and warns about the init of pygame and any mixer >> >> settings. >> >> >> >> Bruce >> >> >> >> >> >> >> >> >> >> Did you get scratchy sound playback with the same application on the >> >> same computer but pygame 1.7? >> >> >> >> does it make a difference if you set the SDL_AUDIODRIVER environment >> >> string to waveout ? >> >> >> >> On Sat, Mar 22, 2008 at 6:37 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> >> > I have just tried the RC5 build from >> >> > http://www3.telus.net/len_l/pygame.htm . >> >> > Graphicly everything seem to work well so far but the music output >> >> > sounds really awful. Very scratchy sound. >> >> > I am running on python 2.5 , Windows Vista, and the machine is >> >> > an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. >> >> > >> >> > My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) >> >> > Been trying different setting but it does not sound good, default >> >> settings >> >> > was a bit better but still very scratchy. Any ideas ? >> >> > >> >> > Regards >> >> > Bo Jangeborg >> >> > >> >> >> >> >> >> >> >> >> >> -- >> >> No virus found in this incoming message. >> >> Checked by AVG. >> >> Version: 7.5.519 / Virus Database: 269.21.8/1338 - Release Date: 3/21/2008 >> >> 5:52 PM >> >> >> >> >> >> >> > >> > >> >> >> > >
Re: [pygame] vista testing...
ok, thanks. Yeah. The problem only seems to happen with some machines. I think it's related to certain inbuilt sound cards. On Mon, Mar 24, 2008 at 10:31 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > Did try * 6, now I even tried 1024*9, still sounds awful. > Have you tested 44k output on XP ? > > René Dudfield skrev: > > > > Thanks for your testing Bo. > > > > I guess if you used 1024 * 3 * 2 for 44K sound then it wouldn't be > > scratchy too. This is because you need twice the buffer size to avoid > > scratchyness as compared to 22K sound - which is half the size of the > > 44K sound. > > > > Thanks for the tip about the Sound object not raising an exception. > > I'll add a few more unit tests for the sound stuff. > > > > > > cheers, > > > > > > On Mon, Mar 24, 2008 at 8:27 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > > >> The buffer setting doesn't seem to make a differens. > >> The key seem to be the sampling rate. Lots of scratching at 44k sound > >> but OK at 22k. But even then I get scratches if I start some way into > >> the music > >> rather then at the start. The later problem I had in pygame 1.7 too. > >> > >> In pygame 1.7 music worked OK in Vista at 44k. > >> I have tried both ogg and mp3 in pygame 1.8. > >> Have you tried playing music at 44k on XP machines? Maybe this is a more > >> general problem. > >> > >> Another thing that seem to have changed is that if a path to a sound file > >> is wrong it doesn't cause an exception. Instead it returns an empty > >> sound object.. > >> Is that really intended ? > >> > >> > >> > >> René Dudfield skrev: > >> > >> > >> > >>> yeah, I think generally increasing the buffer size helps people. > >>> > >> > > >> > For rc5 I increased the default buffer size to 1024 * 3... which has > >> > worked in the past to fix things up on most peoples computers. > >> > > >> > Unfortunately increasing it over 3*1024 starts to make the sound lag > >> > noticable... at least to me. So I think it will have to be a per > >> > game, or per user setting until it gets fixed propperly. > >> > > >> > > >> > If someone could lodge a bug report at: > >> > http://bugzilla.libsdl.org/ > >> > > >> > That would be greatly appreciated. > >> > > >> > I think it's best to fix this properly in SDL_mixer... but for now the > >> > work around is to increase the default buffer size on a per computer > >> > basis. > >> > > >> > cheers, > >> > > >> > > >> > > >> > On Sun, Mar 23, 2008 at 8:54 AM, FT <[EMAIL PROTECTED]> wrote: > >> > > >> >> Hi! > >> >> > >> >> I think there was also an issue of pre-init for any init would > wipe out > >> >> any settings. So the pre-init was setup to prevent the loss of any > settings > >> >> besides the size of the buffer to hold the data. The issue comes up > all the > >> >> time and is in the specs on the mixer and sound. Where it recommends > >> >> increasing the buffer size and warns about the init of pygame and > any mixer > >> >> settings. > >> >> > >> >> Bruce > >> >> > >> >> > >> >> > >> >> > >> >> Did you get scratchy sound playback with the same application on the > >> >> same computer but pygame 1.7? > >> >> > >> >> does it make a difference if you set the SDL_AUDIODRIVER environment > >> >> string to waveout ? > >> >> > >> >> On Sat, Mar 22, 2008 at 6:37 AM, Bo Jangeborg <[EMAIL PROTECTED]> > wrote: > >> >> > I have just tried the RC5 build from > >> >> > http://www3.telus.net/len_l/pygame.htm . > >> >> > Graphicly everything seem to work well so far but the music output > >> >> > sounds really awful. Very scratchy sound. > >> >> > I am running on python 2.5 , Windows Vista, and the machine is > >> >> > an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster > X-Fi. > >> >> > > >> >> > My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) > >> >> > Been trying different setting but it does not sound good, default > >> >> settings > >> >> > was a bit better but still very scratchy. Any ideas ? > >> >> > > >> >> > Regards > >> >> > Bo Jangeborg > >> >> > > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> No virus found in this incoming message. > >> >> Checked by AVG. > >> >> Version: 7.5.519 / Virus Database: 269.21.8/1338 - Release Date: > 3/21/2008 > >> >> 5:52 PM > >> >> > >> >> > >> >> > >> > > >> > > >> > >> > >> > > > > > >
Re: [pygame] vista testing...
Did try * 6, now I even tried 1024*9, still sounds awful. Have you tested 44k output on XP ? René Dudfield skrev: Thanks for your testing Bo. I guess if you used 1024 * 3 * 2 for 44K sound then it wouldn't be scratchy too. This is because you need twice the buffer size to avoid scratchyness as compared to 22K sound - which is half the size of the 44K sound. Thanks for the tip about the Sound object not raising an exception. I'll add a few more unit tests for the sound stuff. cheers, On Mon, Mar 24, 2008 at 8:27 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: The buffer setting doesn't seem to make a differens. The key seem to be the sampling rate. Lots of scratching at 44k sound but OK at 22k. But even then I get scratches if I start some way into the music rather then at the start. The later problem I had in pygame 1.7 too. In pygame 1.7 music worked OK in Vista at 44k. I have tried both ogg and mp3 in pygame 1.8. Have you tried playing music at 44k on XP machines? Maybe this is a more general problem. Another thing that seem to have changed is that if a path to a sound file is wrong it doesn't cause an exception. Instead it returns an empty sound object.. Is that really intended ? René Dudfield skrev: yeah, I think generally increasing the buffer size helps people. > > For rc5 I increased the default buffer size to 1024 * 3... which has > worked in the past to fix things up on most peoples computers. > > Unfortunately increasing it over 3*1024 starts to make the sound lag > noticable... at least to me. So I think it will have to be a per > game, or per user setting until it gets fixed propperly. > > > If someone could lodge a bug report at: > http://bugzilla.libsdl.org/ > > That would be greatly appreciated. > > I think it's best to fix this properly in SDL_mixer... but for now the > work around is to increase the default buffer size on a per computer > basis. > > cheers, > > > > On Sun, Mar 23, 2008 at 8:54 AM, FT <[EMAIL PROTECTED]> wrote: > >> Hi! >> >> I think there was also an issue of pre-init for any init would wipe out >> any settings. So the pre-init was setup to prevent the loss of any settings >> besides the size of the buffer to hold the data. The issue comes up all the >> time and is in the specs on the mixer and sound. Where it recommends >> increasing the buffer size and warns about the init of pygame and any mixer >> settings. >> >> Bruce >> >> >> >> >> Did you get scratchy sound playback with the same application on the >> same computer but pygame 1.7? >> >> does it make a difference if you set the SDL_AUDIODRIVER environment >> string to waveout ? >> >> On Sat, Mar 22, 2008 at 6:37 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: >> > I have just tried the RC5 build from >> > http://www3.telus.net/len_l/pygame.htm . >> > Graphicly everything seem to work well so far but the music output >> > sounds really awful. Very scratchy sound. >> > I am running on python 2.5 , Windows Vista, and the machine is >> > an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. >> > >> > My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) >> > Been trying different setting but it does not sound good, default >> settings >> > was a bit better but still very scratchy. Any ideas ? >> > >> > Regards >> > Bo Jangeborg >> > >> >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG. >> Version: 7.5.519 / Virus Database: 269.21.8/1338 - Release Date: 3/21/2008 >> 5:52 PM >> >> >> > >
Re: [pygame] vista testing...
Thanks for your testing Bo. I guess if you used 1024 * 3 * 2 for 44K sound then it wouldn't be scratchy too. This is because you need twice the buffer size to avoid scratchyness as compared to 22K sound - which is half the size of the 44K sound. Thanks for the tip about the Sound object not raising an exception. I'll add a few more unit tests for the sound stuff. cheers, On Mon, Mar 24, 2008 at 8:27 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > The buffer setting doesn't seem to make a differens. > The key seem to be the sampling rate. Lots of scratching at 44k sound > but OK at 22k. But even then I get scratches if I start some way into > the music > rather then at the start. The later problem I had in pygame 1.7 too. > > In pygame 1.7 music worked OK in Vista at 44k. > I have tried both ogg and mp3 in pygame 1.8. > Have you tried playing music at 44k on XP machines? Maybe this is a more > general problem. > > Another thing that seem to have changed is that if a path to a sound file > is wrong it doesn't cause an exception. Instead it returns an empty > sound object.. > Is that really intended ? > > > > René Dudfield skrev: > > > > yeah, I think generally increasing the buffer size helps people. > > > > For rc5 I increased the default buffer size to 1024 * 3... which has > > worked in the past to fix things up on most peoples computers. > > > > Unfortunately increasing it over 3*1024 starts to make the sound lag > > noticable... at least to me. So I think it will have to be a per > > game, or per user setting until it gets fixed propperly. > > > > > > If someone could lodge a bug report at: > > http://bugzilla.libsdl.org/ > > > > That would be greatly appreciated. > > > > I think it's best to fix this properly in SDL_mixer... but for now the > > work around is to increase the default buffer size on a per computer > > basis. > > > > cheers, > > > > > > > > On Sun, Mar 23, 2008 at 8:54 AM, FT <[EMAIL PROTECTED]> wrote: > > > >> Hi! > >> > >> I think there was also an issue of pre-init for any init would wipe > out > >> any settings. So the pre-init was setup to prevent the loss of any > settings > >> besides the size of the buffer to hold the data. The issue comes up all > the > >> time and is in the specs on the mixer and sound. Where it recommends > >> increasing the buffer size and warns about the init of pygame and any > mixer > >> settings. > >> > >> Bruce > >> > >> > >> > >> > >> Did you get scratchy sound playback with the same application on the > >> same computer but pygame 1.7? > >> > >> does it make a difference if you set the SDL_AUDIODRIVER environment > >> string to waveout ? > >> > >> On Sat, Mar 22, 2008 at 6:37 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > >> > I have just tried the RC5 build from > >> > http://www3.telus.net/len_l/pygame.htm . > >> > Graphicly everything seem to work well so far but the music output > >> > sounds really awful. Very scratchy sound. > >> > I am running on python 2.5 , Windows Vista, and the machine is > >> > an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. > >> > > >> > My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) > >> > Been trying different setting but it does not sound good, default > >> settings > >> > was a bit better but still very scratchy. Any ideas ? > >> > > >> > Regards > >> > Bo Jangeborg > >> > > >> > >> > >> > >> > >> -- > >> No virus found in this incoming message. > >> Checked by AVG. > >> Version: 7.5.519 / Virus Database: 269.21.8/1338 - Release Date: > 3/21/2008 > >> 5:52 PM > >> > >> > >> > > > > > >
Re: [pygame] vista testing...
The buffer setting doesn't seem to make a differens. The key seem to be the sampling rate. Lots of scratching at 44k sound but OK at 22k. But even then I get scratches if I start some way into the music rather then at the start. The later problem I had in pygame 1.7 too. In pygame 1.7 music worked OK in Vista at 44k. I have tried both ogg and mp3 in pygame 1.8. Have you tried playing music at 44k on XP machines? Maybe this is a more general problem. Another thing that seem to have changed is that if a path to a sound file is wrong it doesn't cause an exception. Instead it returns an empty sound object.. Is that really intended ? René Dudfield skrev: yeah, I think generally increasing the buffer size helps people. For rc5 I increased the default buffer size to 1024 * 3... which has worked in the past to fix things up on most peoples computers. Unfortunately increasing it over 3*1024 starts to make the sound lag noticable... at least to me. So I think it will have to be a per game, or per user setting until it gets fixed propperly. If someone could lodge a bug report at: http://bugzilla.libsdl.org/ That would be greatly appreciated. I think it's best to fix this properly in SDL_mixer... but for now the work around is to increase the default buffer size on a per computer basis. cheers, On Sun, Mar 23, 2008 at 8:54 AM, FT <[EMAIL PROTECTED]> wrote: Hi! I think there was also an issue of pre-init for any init would wipe out any settings. So the pre-init was setup to prevent the loss of any settings besides the size of the buffer to hold the data. The issue comes up all the time and is in the specs on the mixer and sound. Where it recommends increasing the buffer size and warns about the init of pygame and any mixer settings. Bruce Did you get scratchy sound playback with the same application on the same computer but pygame 1.7? does it make a difference if you set the SDL_AUDIODRIVER environment string to waveout ? On Sat, Mar 22, 2008 at 6:37 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > I have just tried the RC5 build from > http://www3.telus.net/len_l/pygame.htm . > Graphicly everything seem to work well so far but the music output > sounds really awful. Very scratchy sound. > I am running on python 2.5 , Windows Vista, and the machine is > an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. > > My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) > Been trying different setting but it does not sound good, default settings > was a bit better but still very scratchy. Any ideas ? > > Regards > Bo Jangeborg > -- No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.21.8/1338 - Release Date: 3/21/2008 5:52 PM
Re: [pygame] vista testing...
yeah, I think generally increasing the buffer size helps people. For rc5 I increased the default buffer size to 1024 * 3... which has worked in the past to fix things up on most peoples computers. Unfortunately increasing it over 3*1024 starts to make the sound lag noticable... at least to me. So I think it will have to be a per game, or per user setting until it gets fixed propperly. If someone could lodge a bug report at: http://bugzilla.libsdl.org/ That would be greatly appreciated. I think it's best to fix this properly in SDL_mixer... but for now the work around is to increase the default buffer size on a per computer basis. cheers, On Sun, Mar 23, 2008 at 8:54 AM, FT <[EMAIL PROTECTED]> wrote: > Hi! > > I think there was also an issue of pre-init for any init would wipe out > any settings. So the pre-init was setup to prevent the loss of any settings > besides the size of the buffer to hold the data. The issue comes up all the > time and is in the specs on the mixer and sound. Where it recommends > increasing the buffer size and warns about the init of pygame and any mixer > settings. > > Bruce > > > > > Did you get scratchy sound playback with the same application on the > same computer but pygame 1.7? > > does it make a difference if you set the SDL_AUDIODRIVER environment > string to waveout ? > > On Sat, Mar 22, 2008 at 6:37 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > > I have just tried the RC5 build from > > http://www3.telus.net/len_l/pygame.htm . > > Graphicly everything seem to work well so far but the music output > > sounds really awful. Very scratchy sound. > > I am running on python 2.5 , Windows Vista, and the machine is > > an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. > > > > My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) > > Been trying different setting but it does not sound good, default > settings > > was a bit better but still very scratchy. Any ideas ? > > > > Regards > > Bo Jangeborg > > > > > > > -- > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.21.8/1338 - Release Date: 3/21/2008 > 5:52 PM > >
Re: [pygame] vista testing...
Hi! I think there was also an issue of pre-init for any init would wipe out any settings. So the pre-init was setup to prevent the loss of any settings besides the size of the buffer to hold the data. The issue comes up all the time and is in the specs on the mixer and sound. Where it recommends increasing the buffer size and warns about the init of pygame and any mixer settings. Bruce Did you get scratchy sound playback with the same application on the same computer but pygame 1.7? does it make a difference if you set the SDL_AUDIODRIVER environment string to waveout ? On Sat, Mar 22, 2008 at 6:37 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > I have just tried the RC5 build from > http://www3.telus.net/len_l/pygame.htm . > Graphicly everything seem to work well so far but the music output > sounds really awful. Very scratchy sound. > I am running on python 2.5 , Windows Vista, and the machine is > an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. > > My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) > Been trying different setting but it does not sound good, default settings > was a bit better but still very scratchy. Any ideas ? > > Regards > Bo Jangeborg > -- No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.21.8/1338 - Release Date: 3/21/2008 5:52 PM
Re: [pygame] vista testing...
Did you get scratchy sound playback with the same application on the same computer but pygame 1.7? does it make a difference if you set the SDL_AUDIODRIVER environment string to waveout ? On Sat, Mar 22, 2008 at 6:37 AM, Bo Jangeborg <[EMAIL PROTECTED]> wrote: > I have just tried the RC5 build from > http://www3.telus.net/len_l/pygame.htm . > Graphicly everything seem to work well so far but the music output > sounds really awful. Very scratchy sound. > I am running on python 2.5 , Windows Vista, and the machine is > an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. > > My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) > Been trying different setting but it does not sound good, default settings > was a bit better but still very scratchy. Any ideas ? > > Regards > Bo Jangeborg >
Re: [pygame] vista testing...
Hi! Did you try 4096 instead of 2048? It is a problem as the specs say. It is what is in cash verses load speed to get the sound started... I have just tried the RC5 build from http://www3.telus.net/len_l/pygame.htm . Graphicly everything seem to work well so far but the music output sounds really awful. Very scratchy sound. I am running on python 2.5 , Windows Vista, and the machine is an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) Been trying different setting but it does not sound good, default settings was a bit better but still very scratchy. Any ideas ? Regards Bo Jangeborg René Dudfield skrev: > Nice one :) > > I guess I'll do an RC5 release tonight... (+3 till 5 hours from now). > > Hopefully that'll be the last one. > > > On Mon, Mar 17, 2008 at 3:02 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > >> OK, pygame building is more friendly to msi's now (rc is now called b >> for beta when building msi's) >> >> my automated builds now have an msi for py2.5: >> http://thorbrian.com/pygame/builds.php >> seems to work fine on vista >> >> >> >> >> On Sun, Mar 16, 2008 at 3:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >> > Nice one. >> > >> > Yeah, I think uninstall gets broken on vista with the .exe ones. I >> > haven't tried it, but that's what it seems to be trying to do - >> > install a registry key so it can uninstall it later. >> > >> > >> > >> > >> > On Mon, Mar 17, 2008 at 9:25 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: >> > > yeah, msi seems the way to go. I think it's also better for 64-bit >> > > windows. The original wininst developer posted in a thread that he >> > > thinks it had a good life, and is fine with it being replaced by >> > > bdist_msi. >> > > >> > > I just installed vista recently, and I've been working today on making >> > > my automated builds use msi. >> > > >> > > ... but for what it's worth, the vista install errors with the .exe >> > > installers are generally fine to ignore, they don't affect pygame's >> > > functionality in any way I've been able to tell. >> > > >> > > >> > > >> > > On Sun, Mar 16, 2008 at 2:37 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >> > > > Hi, >> > > > >> > > > I've tried to add a manifest with mt.exe but have not been able to get >> > > > it to work. It kept creating an executable with only 60KB size. >> > > > >> > > > I think the manifest needs a bunch of tweaking. >> > > > >> > > > However then I started reading up about blue screens caused by the >> > > > manifests on windows XP... >> > > > >> > > > So, let's use the msi build instead? Python uses a msi build anyway, >> > > > so the requirement is there already. The msi build installs ok on >> > > > vista, and asks for permission. >> > > > >> > > > I guess the only issue with that is the version string renaming, >> > > > because the msi doesn't like our version strings. I think that could >> > > > be fixed with someway to tell the installer to use a different naming >> > > > scheme. Or I guess we could ditch our old naming scheme, and change >> > > > it a little. But for this 1.8 release I think we should just stick >> > > > with the current naming, and change it for after pygame 1.8. >> > > > >> > > > cheers, >> > > > >> > > > >> > > > >> > > > >> > > > On Sun, Feb 17, 2008 at 6:40 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: >> > > > > I couldn't find mt.exe in the platform SDK or .NET SDK's I've got >> > > > > installed - but I found it bundled with Visual Studio 2005. >> > > > > >> > > > > so I posted it here: >> > > > > thorbrian.com/mt.zip >> > > > > >> > > > > I think the usage to change a manifest is: >> > > > > mt -manifest -outputresource: >> > > > > >> > > > > and the usage to extract a manifest is: >> > > > > mt.exe -inputresource: -out: >> > > > > >> > > > > attached is a manifest I've used at work for installer-type-programs >> > > > > >> > > > > ... as a side note it looks like there is no manifest for the >> > > > > installer bdist_wininst makes for me, and without setup or installer >> > > > > in the name windows probably isn't auto-detecting and triggering it's >> > > > > "treat as an installer" behavior, so I'm kind of surprised it isn't >> > > > > virtualizing the environment for the installer and letting it think it >> > > > > has full access... >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > On Feb 15, 2008 9:18 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: >> > > > > > There's an command line mt.exe tool by microsoft that does it - I >> > > > > > think it comes with either the .NET or the Platform SDK, but I'm not >> > > > > > sure. You just create an xml manifest file with the righ
Re: [pygame] vista testing...
I have just tried the RC5 build from http://www3.telus.net/len_l/pygame.htm . Graphicly everything seem to work well so far but the music output sounds really awful. Very scratchy sound. I am running on python 2.5 , Windows Vista, and the machine is an Intel core 2 cpu 6700 2.66 Ghz. Soundcard is a Soundblaster X-Fi. My standard setting is pygame.mixer.pre_init(44100, -16, 2, 2048) Been trying different setting but it does not sound good, default settings was a bit better but still very scratchy. Any ideas ? Regards Bo Jangeborg René Dudfield skrev: Nice one :) I guess I'll do an RC5 release tonight... (+3 till 5 hours from now). Hopefully that'll be the last one. On Mon, Mar 17, 2008 at 3:02 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: OK, pygame building is more friendly to msi's now (rc is now called b for beta when building msi's) my automated builds now have an msi for py2.5: http://thorbrian.com/pygame/builds.php seems to work fine on vista On Sun, Mar 16, 2008 at 3:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > Nice one. > > Yeah, I think uninstall gets broken on vista with the .exe ones. I > haven't tried it, but that's what it seems to be trying to do - > install a registry key so it can uninstall it later. > > > > > On Mon, Mar 17, 2008 at 9:25 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > yeah, msi seems the way to go. I think it's also better for 64-bit > > windows. The original wininst developer posted in a thread that he > > thinks it had a good life, and is fine with it being replaced by > > bdist_msi. > > > > I just installed vista recently, and I've been working today on making > > my automated builds use msi. > > > > ... but for what it's worth, the vista install errors with the .exe > > installers are generally fine to ignore, they don't affect pygame's > > functionality in any way I've been able to tell. > > > > > > > > On Sun, Mar 16, 2008 at 2:37 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I've tried to add a manifest with mt.exe but have not been able to get > > > it to work. It kept creating an executable with only 60KB size. > > > > > > I think the manifest needs a bunch of tweaking. > > > > > > However then I started reading up about blue screens caused by the > > > manifests on windows XP... > > > > > > So, let's use the msi build instead? Python uses a msi build anyway, > > > so the requirement is there already. The msi build installs ok on > > > vista, and asks for permission. > > > > > > I guess the only issue with that is the version string renaming, > > > because the msi doesn't like our version strings. I think that could > > > be fixed with someway to tell the installer to use a different naming > > > scheme. Or I guess we could ditch our old naming scheme, and change > > > it a little. But for this 1.8 release I think we should just stick > > > with the current naming, and change it for after pygame 1.8. > > > > > > cheers, > > > > > > > > > > > > > > > On Sun, Feb 17, 2008 at 6:40 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > > I couldn't find mt.exe in the platform SDK or .NET SDK's I've got > > > > installed - but I found it bundled with Visual Studio 2005. > > > > > > > > so I posted it here: > > > > thorbrian.com/mt.zip > > > > > > > > I think the usage to change a manifest is: > > > > mt -manifest -outputresource: > > > > > > > > and the usage to extract a manifest is: > > > > mt.exe -inputresource: -out: > > > > > > > > attached is a manifest I've used at work for installer-type-programs > > > > > > > > ... as a side note it looks like there is no manifest for the > > > > installer bdist_wininst makes for me, and without setup or installer > > > > in the name windows probably isn't auto-detecting and triggering it's > > > > "treat as an installer" behavior, so I'm kind of surprised it isn't > > > > virtualizing the environment for the installer and letting it think it > > > > has full access... > > > > > > > > > > > > > > > > > > > > On Feb 15, 2008 9:18 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > > > There's an command line mt.exe tool by microsoft that does it - I > > > > > think it comes with either the .NET or the Platform SDK, but I'm not > > > > > sure. You just create an xml manifest file with the right > > > > > requestedExecutionLevel, then run mt -manifest with some args or > > > > > something like that. all it does is embed the xml file as a resource. > > > > > > > > > > It can also be done with any old resource editor if you know the right > > > > > name and id for the resource (you can figure that out by using the > > > > > editor to look at a file that does have a manif
Re: [pygame] vista testing...
Nice one :) I guess I'll do an RC5 release tonight... (+3 till 5 hours from now). Hopefully that'll be the last one. On Mon, Mar 17, 2008 at 3:02 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > OK, pygame building is more friendly to msi's now (rc is now called b > for beta when building msi's) > > my automated builds now have an msi for py2.5: > http://thorbrian.com/pygame/builds.php > seems to work fine on vista > > > > > On Sun, Mar 16, 2008 at 3:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > Nice one. > > > > Yeah, I think uninstall gets broken on vista with the .exe ones. I > > haven't tried it, but that's what it seems to be trying to do - > > install a registry key so it can uninstall it later. > > > > > > > > > > On Mon, Mar 17, 2008 at 9:25 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > yeah, msi seems the way to go. I think it's also better for 64-bit > > > windows. The original wininst developer posted in a thread that he > > > thinks it had a good life, and is fine with it being replaced by > > > bdist_msi. > > > > > > I just installed vista recently, and I've been working today on making > > > my automated builds use msi. > > > > > > ... but for what it's worth, the vista install errors with the .exe > > > installers are generally fine to ignore, they don't affect pygame's > > > functionality in any way I've been able to tell. > > > > > > > > > > > > On Sun, Mar 16, 2008 at 2:37 PM, René Dudfield <[EMAIL PROTECTED]> > wrote: > > > > Hi, > > > > > > > > I've tried to add a manifest with mt.exe but have not been able to > get > > > > it to work. It kept creating an executable with only 60KB size. > > > > > > > > I think the manifest needs a bunch of tweaking. > > > > > > > > However then I started reading up about blue screens caused by the > > > > manifests on windows XP... > > > > > > > > So, let's use the msi build instead? Python uses a msi build > anyway, > > > > so the requirement is there already. The msi build installs ok on > > > > vista, and asks for permission. > > > > > > > > I guess the only issue with that is the version string renaming, > > > > because the msi doesn't like our version strings. I think that > could > > > > be fixed with someway to tell the installer to use a different > naming > > > > scheme. Or I guess we could ditch our old naming scheme, and change > > > > it a little. But for this 1.8 release I think we should just stick > > > > with the current naming, and change it for after pygame 1.8. > > > > > > > > cheers, > > > > > > > > > > > > > > > > > > > > On Sun, Feb 17, 2008 at 6:40 AM, Brian Fisher <[EMAIL PROTECTED]> > wrote: > > > > > I couldn't find mt.exe in the platform SDK or .NET SDK's I've got > > > > > installed - but I found it bundled with Visual Studio 2005. > > > > > > > > > > so I posted it here: > > > > > thorbrian.com/mt.zip > > > > > > > > > > I think the usage to change a manifest is: > > > > > mt -manifest -outputresource: > > > > > > > > > > and the usage to extract a manifest is: > > > > > mt.exe -inputresource: -out: > > > > > > > > > > attached is a manifest I've used at work for > installer-type-programs > > > > > > > > > > ... as a side note it looks like there is no manifest for the > > > > > installer bdist_wininst makes for me, and without setup or > installer > > > > > in the name windows probably isn't auto-detecting and triggering > it's > > > > > "treat as an installer" behavior, so I'm kind of surprised it > isn't > > > > > virtualizing the environment for the installer and letting it > think it > > > > > has full access... > > > > > > > > > > > > > > > > > > > > > > > > > On Feb 15, 2008 9:18 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > > > > There's an command line mt.exe tool by microsoft that does it > - I > > > > > > think it comes with either the .NET or the Platform SDK, but > I'm not > > > > > > sure. You just create an xml manifest file with the right > > > > > > requestedExecutionLevel, then run mt -manifest with some args > or > > > > > > something like that. all it does is embed the xml file as a > resource. > > > > > > > > > > > > It can also be done with any old resource editor if you know > the right > > > > > > name and id for the resource (you can figure that out by using > the > > > > > > editor to look at a file that does have a manifest - like an > inno > > > > > > setup installer for instance) > > > > > > > > > > > > > > > > > > On Feb 15, 2008 6:33 PM, René Dudfield <[EMAIL PROTECTED]> > wrote: > > > > > > > ah, cool. > > > > > > > > > > > > > > Here's a couple of links from a search for more info: > > > > > > > http://
Re: [pygame] vista testing...
OK, pygame building is more friendly to msi's now (rc is now called b for beta when building msi's) my automated builds now have an msi for py2.5: http://thorbrian.com/pygame/builds.php seems to work fine on vista On Sun, Mar 16, 2008 at 3:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > Nice one. > > Yeah, I think uninstall gets broken on vista with the .exe ones. I > haven't tried it, but that's what it seems to be trying to do - > install a registry key so it can uninstall it later. > > > > > On Mon, Mar 17, 2008 at 9:25 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > yeah, msi seems the way to go. I think it's also better for 64-bit > > windows. The original wininst developer posted in a thread that he > > thinks it had a good life, and is fine with it being replaced by > > bdist_msi. > > > > I just installed vista recently, and I've been working today on making > > my automated builds use msi. > > > > ... but for what it's worth, the vista install errors with the .exe > > installers are generally fine to ignore, they don't affect pygame's > > functionality in any way I've been able to tell. > > > > > > > > On Sun, Mar 16, 2008 at 2:37 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I've tried to add a manifest with mt.exe but have not been able to get > > > it to work. It kept creating an executable with only 60KB size. > > > > > > I think the manifest needs a bunch of tweaking. > > > > > > However then I started reading up about blue screens caused by the > > > manifests on windows XP... > > > > > > So, let's use the msi build instead? Python uses a msi build anyway, > > > so the requirement is there already. The msi build installs ok on > > > vista, and asks for permission. > > > > > > I guess the only issue with that is the version string renaming, > > > because the msi doesn't like our version strings. I think that could > > > be fixed with someway to tell the installer to use a different naming > > > scheme. Or I guess we could ditch our old naming scheme, and change > > > it a little. But for this 1.8 release I think we should just stick > > > with the current naming, and change it for after pygame 1.8. > > > > > > cheers, > > > > > > > > > > > > > > > On Sun, Feb 17, 2008 at 6:40 AM, Brian Fisher <[EMAIL PROTECTED]> > wrote: > > > > I couldn't find mt.exe in the platform SDK or .NET SDK's I've got > > > > installed - but I found it bundled with Visual Studio 2005. > > > > > > > > so I posted it here: > > > > thorbrian.com/mt.zip > > > > > > > > I think the usage to change a manifest is: > > > > mt -manifest -outputresource: > > > > > > > > and the usage to extract a manifest is: > > > > mt.exe -inputresource: -out: > > > > > > > > attached is a manifest I've used at work for installer-type-programs > > > > > > > > ... as a side note it looks like there is no manifest for the > > > > installer bdist_wininst makes for me, and without setup or installer > > > > in the name windows probably isn't auto-detecting and triggering > it's > > > > "treat as an installer" behavior, so I'm kind of surprised it isn't > > > > virtualizing the environment for the installer and letting it think > it > > > > has full access... > > > > > > > > > > > > > > > > > > > > On Feb 15, 2008 9:18 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > > > There's an command line mt.exe tool by microsoft that does it - I > > > > > think it comes with either the .NET or the Platform SDK, but I'm > not > > > > > sure. You just create an xml manifest file with the right > > > > > requestedExecutionLevel, then run mt -manifest with some args or > > > > > something like that. all it does is embed the xml file as a > resource. > > > > > > > > > > It can also be done with any old resource editor if you know the > right > > > > > name and id for the resource (you can figure that out by using the > > > > > editor to look at a file that does have a manifest - like an inno > > > > > setup installer for instance) > > > > > > > > > > > > > > > On Feb 15, 2008 6:33 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > > > > ah, cool. > > > > > > > > > > > > Here's a couple of links from a search for more info: > > > > > > http://channel9.msdn.com/Showpost.aspx?postid=211271 > > > > > > http://channel9.msdn.com/Showpost.aspx?postid=209647 > > > > > > > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=463884&SiteID=1 > > > > > > > > > > > > I think it should be fairly straight forward... but I can't > seem to > > > > > > find out to actually add the manifest to an exe. > > > > > > > > > > > > Do you know how to add a manifest to an exe? > > > > > > > > > > > > cheers, > > > > > > > > > > > > > > > > > > On
Re: [pygame] vista testing...
Nice one. Yeah, I think uninstall gets broken on vista with the .exe ones. I haven't tried it, but that's what it seems to be trying to do - install a registry key so it can uninstall it later. On Mon, Mar 17, 2008 at 9:25 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > yeah, msi seems the way to go. I think it's also better for 64-bit > windows. The original wininst developer posted in a thread that he > thinks it had a good life, and is fine with it being replaced by > bdist_msi. > > I just installed vista recently, and I've been working today on making > my automated builds use msi. > > ... but for what it's worth, the vista install errors with the .exe > installers are generally fine to ignore, they don't affect pygame's > functionality in any way I've been able to tell. > > > > On Sun, Mar 16, 2008 at 2:37 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I've tried to add a manifest with mt.exe but have not been able to get > > it to work. It kept creating an executable with only 60KB size. > > > > I think the manifest needs a bunch of tweaking. > > > > However then I started reading up about blue screens caused by the > > manifests on windows XP... > > > > So, let's use the msi build instead? Python uses a msi build anyway, > > so the requirement is there already. The msi build installs ok on > > vista, and asks for permission. > > > > I guess the only issue with that is the version string renaming, > > because the msi doesn't like our version strings. I think that could > > be fixed with someway to tell the installer to use a different naming > > scheme. Or I guess we could ditch our old naming scheme, and change > > it a little. But for this 1.8 release I think we should just stick > > with the current naming, and change it for after pygame 1.8. > > > > cheers, > > > > > > > > > > On Sun, Feb 17, 2008 at 6:40 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > I couldn't find mt.exe in the platform SDK or .NET SDK's I've got > > > installed - but I found it bundled with Visual Studio 2005. > > > > > > so I posted it here: > > > thorbrian.com/mt.zip > > > > > > I think the usage to change a manifest is: > > > mt -manifest -outputresource: > > > > > > and the usage to extract a manifest is: > > > mt.exe -inputresource: -out: > > > > > > attached is a manifest I've used at work for installer-type-programs > > > > > > ... as a side note it looks like there is no manifest for the > > > installer bdist_wininst makes for me, and without setup or installer > > > in the name windows probably isn't auto-detecting and triggering it's > > > "treat as an installer" behavior, so I'm kind of surprised it isn't > > > virtualizing the environment for the installer and letting it think it > > > has full access... > > > > > > > > > > > > > > > On Feb 15, 2008 9:18 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > > There's an command line mt.exe tool by microsoft that does it - I > > > > think it comes with either the .NET or the Platform SDK, but I'm not > > > > sure. You just create an xml manifest file with the right > > > > requestedExecutionLevel, then run mt -manifest with some args or > > > > something like that. all it does is embed the xml file as a resource. > > > > > > > > It can also be done with any old resource editor if you know the > right > > > > name and id for the resource (you can figure that out by using the > > > > editor to look at a file that does have a manifest - like an inno > > > > setup installer for instance) > > > > > > > > > > > > On Feb 15, 2008 6:33 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > > > ah, cool. > > > > > > > > > > Here's a couple of links from a search for more info: > > > > > http://channel9.msdn.com/Showpost.aspx?postid=211271 > > > > > http://channel9.msdn.com/Showpost.aspx?postid=209647 > > > > > > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=463884&SiteID=1 > > > > > > > > > > I think it should be fairly straight forward... but I can't seem to > > > > > find out to actually add the manifest to an exe. > > > > > > > > > > Do you know how to add a manifest to an exe? > > > > > > > > > > cheers, > > > > > > > > > > > > > > > On Feb 16, 2008 11:29 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > > > > On Vista if a program doesn't have a "manifest" that tells Vista > > > > > > whether it wants to ask for permissions or not, the default > behavior > > > > > > is for Vista to let it think that it is writing and doing a > bunch of > > > > > > things that would affect all users on XP, but virtualize them in > a way > > > > > > that is per user (and can be lost or wiped as well). The > manifest can > > > > > > tell the OS to either ask for elevation of privilege to let it do > > > > > > things for all users (the t
Re: [pygame] vista testing...
yeah, msi seems the way to go. I think it's also better for 64-bit windows. The original wininst developer posted in a thread that he thinks it had a good life, and is fine with it being replaced by bdist_msi. I just installed vista recently, and I've been working today on making my automated builds use msi. ... but for what it's worth, the vista install errors with the .exe installers are generally fine to ignore, they don't affect pygame's functionality in any way I've been able to tell. On Sun, Mar 16, 2008 at 2:37 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > Hi, > > I've tried to add a manifest with mt.exe but have not been able to get > it to work. It kept creating an executable with only 60KB size. > > I think the manifest needs a bunch of tweaking. > > However then I started reading up about blue screens caused by the > manifests on windows XP... > > So, let's use the msi build instead? Python uses a msi build anyway, > so the requirement is there already. The msi build installs ok on > vista, and asks for permission. > > I guess the only issue with that is the version string renaming, > because the msi doesn't like our version strings. I think that could > be fixed with someway to tell the installer to use a different naming > scheme. Or I guess we could ditch our old naming scheme, and change > it a little. But for this 1.8 release I think we should just stick > with the current naming, and change it for after pygame 1.8. > > cheers, > > > > > On Sun, Feb 17, 2008 at 6:40 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > I couldn't find mt.exe in the platform SDK or .NET SDK's I've got > > installed - but I found it bundled with Visual Studio 2005. > > > > so I posted it here: > > thorbrian.com/mt.zip > > > > I think the usage to change a manifest is: > > mt -manifest -outputresource: > > > > and the usage to extract a manifest is: > > mt.exe -inputresource: -out: > > > > attached is a manifest I've used at work for installer-type-programs > > > > ... as a side note it looks like there is no manifest for the > > installer bdist_wininst makes for me, and without setup or installer > > in the name windows probably isn't auto-detecting and triggering it's > > "treat as an installer" behavior, so I'm kind of surprised it isn't > > virtualizing the environment for the installer and letting it think it > > has full access... > > > > > > > > > > On Feb 15, 2008 9:18 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > There's an command line mt.exe tool by microsoft that does it - I > > > think it comes with either the .NET or the Platform SDK, but I'm not > > > sure. You just create an xml manifest file with the right > > > requestedExecutionLevel, then run mt -manifest with some args or > > > something like that. all it does is embed the xml file as a resource. > > > > > > It can also be done with any old resource editor if you know the right > > > name and id for the resource (you can figure that out by using the > > > editor to look at a file that does have a manifest - like an inno > > > setup installer for instance) > > > > > > > > > On Feb 15, 2008 6:33 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > > ah, cool. > > > > > > > > Here's a couple of links from a search for more info: > > > > http://channel9.msdn.com/Showpost.aspx?postid=211271 > > > > http://channel9.msdn.com/Showpost.aspx?postid=209647 > > > > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=463884&SiteID=1 > > > > > > > > I think it should be fairly straight forward... but I can't seem to > > > > find out to actually add the manifest to an exe. > > > > > > > > Do you know how to add a manifest to an exe? > > > > > > > > cheers, > > > > > > > > > > > > On Feb 16, 2008 11:29 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > > > On Vista if a program doesn't have a "manifest" that tells Vista > > > > > whether it wants to ask for permissions or not, the default behavior > > > > > is for Vista to let it think that it is writing and doing a bunch of > > > > > things that would affect all users on XP, but virtualize them in a > way > > > > > that is per user (and can be lost or wiped as well). The manifest > can > > > > > tell the OS to either ask for elevation of privilege to let it do > > > > > things for all users (the trust box), or to have the app run with > > > > > whatever it can get, or to have the app run without special > prvileges. > > > > > > > > > > It sounds like maybe the install has a manifest, but the manifest is > > > > > set to not ask to elevate. > > > > > > > > > > manifests can be modified/added/deleted from finished built exe's as > > > > > long as the exe isn't signed, so if you wanted to play around with > the > > > > > manifest settings you could. > > > > > > > > > > > > > > > On Fri, Feb 15, 2008 at 4:17 PM, René Dudfield <[EMAIL PROTECTED]> >
Re: [pygame] vista testing...
Hi, I've tried to add a manifest with mt.exe but have not been able to get it to work. It kept creating an executable with only 60KB size. I think the manifest needs a bunch of tweaking. However then I started reading up about blue screens caused by the manifests on windows XP... So, let's use the msi build instead? Python uses a msi build anyway, so the requirement is there already. The msi build installs ok on vista, and asks for permission. I guess the only issue with that is the version string renaming, because the msi doesn't like our version strings. I think that could be fixed with someway to tell the installer to use a different naming scheme. Or I guess we could ditch our old naming scheme, and change it a little. But for this 1.8 release I think we should just stick with the current naming, and change it for after pygame 1.8. cheers, On Sun, Feb 17, 2008 at 6:40 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > I couldn't find mt.exe in the platform SDK or .NET SDK's I've got > installed - but I found it bundled with Visual Studio 2005. > > so I posted it here: > thorbrian.com/mt.zip > > I think the usage to change a manifest is: > mt -manifest -outputresource: > > and the usage to extract a manifest is: > mt.exe -inputresource: -out: > > attached is a manifest I've used at work for installer-type-programs > > ... as a side note it looks like there is no manifest for the > installer bdist_wininst makes for me, and without setup or installer > in the name windows probably isn't auto-detecting and triggering it's > "treat as an installer" behavior, so I'm kind of surprised it isn't > virtualizing the environment for the installer and letting it think it > has full access... > > > > > On Feb 15, 2008 9:18 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > There's an command line mt.exe tool by microsoft that does it - I > > think it comes with either the .NET or the Platform SDK, but I'm not > > sure. You just create an xml manifest file with the right > > requestedExecutionLevel, then run mt -manifest with some args or > > something like that. all it does is embed the xml file as a resource. > > > > It can also be done with any old resource editor if you know the right > > name and id for the resource (you can figure that out by using the > > editor to look at a file that does have a manifest - like an inno > > setup installer for instance) > > > > > > On Feb 15, 2008 6:33 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > ah, cool. > > > > > > Here's a couple of links from a search for more info: > > > http://channel9.msdn.com/Showpost.aspx?postid=211271 > > > http://channel9.msdn.com/Showpost.aspx?postid=209647 > > > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=463884&SiteID=1 > > > > > > I think it should be fairly straight forward... but I can't seem to > > > find out to actually add the manifest to an exe. > > > > > > Do you know how to add a manifest to an exe? > > > > > > cheers, > > > > > > > > > On Feb 16, 2008 11:29 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > > On Vista if a program doesn't have a "manifest" that tells Vista > > > > whether it wants to ask for permissions or not, the default behavior > > > > is for Vista to let it think that it is writing and doing a bunch of > > > > things that would affect all users on XP, but virtualize them in a way > > > > that is per user (and can be lost or wiped as well). The manifest can > > > > tell the OS to either ask for elevation of privilege to let it do > > > > things for all users (the trust box), or to have the app run with > > > > whatever it can get, or to have the app run without special prvileges. > > > > > > > > It sounds like maybe the install has a manifest, but the manifest is > > > > set to not ask to elevate. > > > > > > > > manifests can be modified/added/deleted from finished built exe's as > > > > long as the exe isn't signed, so if you wanted to play around with the > > > > manifest settings you could. > > > > > > > > > > > > On Fri, Feb 15, 2008 at 4:17 PM, René Dudfield <[EMAIL PROTECTED]> > wrote: > > > > > - the pygame installer brings up a bunch of messages about things it > can't > > > > > do... but then manages to install ok. I think it's trying to do > things like > > > > > set registry keys, but vista is blocking it. I think this is more > the fault > > > > > of the distutils install maker. Anyone know about changes needed > for vista > > > > > installers? For most installers vista pops up a message about "do > you trust > > > > > this installer". This doesn't happen for the pygame one... so maybe > we have > > > > > to ask vista for permission. > > > > > > > > > > > > > > >
Re: [pygame] vista testing...
I couldn't find mt.exe in the platform SDK or .NET SDK's I've got installed - but I found it bundled with Visual Studio 2005. so I posted it here: thorbrian.com/mt.zip I think the usage to change a manifest is: mt -manifest -outputresource: and the usage to extract a manifest is: mt.exe -inputresource: -out: attached is a manifest I've used at work for installer-type-programs ... as a side note it looks like there is no manifest for the installer bdist_wininst makes for me, and without setup or installer in the name windows probably isn't auto-detecting and triggering it's "treat as an installer" behavior, so I'm kind of surprised it isn't virtualizing the environment for the installer and letting it think it has full access... On Feb 15, 2008 9:18 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > There's an command line mt.exe tool by microsoft that does it - I > think it comes with either the .NET or the Platform SDK, but I'm not > sure. You just create an xml manifest file with the right > requestedExecutionLevel, then run mt -manifest with some args or > something like that. all it does is embed the xml file as a resource. > > It can also be done with any old resource editor if you know the right > name and id for the resource (you can figure that out by using the > editor to look at a file that does have a manifest - like an inno > setup installer for instance) > > > On Feb 15, 2008 6:33 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > ah, cool. > > > > Here's a couple of links from a search for more info: > > http://channel9.msdn.com/Showpost.aspx?postid=211271 > > http://channel9.msdn.com/Showpost.aspx?postid=209647 > > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=463884&SiteID=1 > > > > I think it should be fairly straight forward... but I can't seem to > > find out to actually add the manifest to an exe. > > > > Do you know how to add a manifest to an exe? > > > > cheers, > > > > > > On Feb 16, 2008 11:29 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > On Vista if a program doesn't have a "manifest" that tells Vista > > > whether it wants to ask for permissions or not, the default behavior > > > is for Vista to let it think that it is writing and doing a bunch of > > > things that would affect all users on XP, but virtualize them in a way > > > that is per user (and can be lost or wiped as well). The manifest can > > > tell the OS to either ask for elevation of privilege to let it do > > > things for all users (the trust box), or to have the app run with > > > whatever it can get, or to have the app run without special prvileges. > > > > > > It sounds like maybe the install has a manifest, but the manifest is > > > set to not ask to elevate. > > > > > > manifests can be modified/added/deleted from finished built exe's as > > > long as the exe isn't signed, so if you wanted to play around with the > > > manifest settings you could. > > > > > > > > > On Fri, Feb 15, 2008 at 4:17 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > > - the pygame installer brings up a bunch of messages about things it > > > > can't > > > > do... but then manages to install ok. I think it's trying to do things > > > > like > > > > set registry keys, but vista is blocking it. I think this is more the > > > > fault > > > > of the distutils install maker. Anyone know about changes needed for > > > > vista > > > > installers? For most installers vista pops up a message about "do you > > > > trust > > > > this installer". This doesn't happen for the pygame one... so maybe we > > > > have > > > > to ask vista for permission. > > > > > > > > > > requireadmin.manifest Description: Binary data
Re: [pygame] vista testing...
There's an command line mt.exe tool by microsoft that does it - I think it comes with either the .NET or the Platform SDK, but I'm not sure. You just create an xml manifest file with the right requestedExecutionLevel, then run mt -manifest with some args or something like that. all it does is embed the xml file as a resource. It can also be done with any old resource editor if you know the right name and id for the resource (you can figure that out by using the editor to look at a file that does have a manifest - like an inno setup installer for instance) On Feb 15, 2008 6:33 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > ah, cool. > > Here's a couple of links from a search for more info: > http://channel9.msdn.com/Showpost.aspx?postid=211271 > http://channel9.msdn.com/Showpost.aspx?postid=209647 > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=463884&SiteID=1 > > I think it should be fairly straight forward... but I can't seem to > find out to actually add the manifest to an exe. > > Do you know how to add a manifest to an exe? > > cheers, > > > On Feb 16, 2008 11:29 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > > On Vista if a program doesn't have a "manifest" that tells Vista > > whether it wants to ask for permissions or not, the default behavior > > is for Vista to let it think that it is writing and doing a bunch of > > things that would affect all users on XP, but virtualize them in a way > > that is per user (and can be lost or wiped as well). The manifest can > > tell the OS to either ask for elevation of privilege to let it do > > things for all users (the trust box), or to have the app run with > > whatever it can get, or to have the app run without special prvileges. > > > > It sounds like maybe the install has a manifest, but the manifest is > > set to not ask to elevate. > > > > manifests can be modified/added/deleted from finished built exe's as > > long as the exe isn't signed, so if you wanted to play around with the > > manifest settings you could. > > > > > > On Fri, Feb 15, 2008 at 4:17 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > - the pygame installer brings up a bunch of messages about things it can't > > > do... but then manages to install ok. I think it's trying to do things > > > like > > > set registry keys, but vista is blocking it. I think this is more the > > > fault > > > of the distutils install maker. Anyone know about changes needed for > > > vista > > > installers? For most installers vista pops up a message about "do you > > > trust > > > this installer". This doesn't happen for the pygame one... so maybe we > > > have > > > to ask vista for permission. > > > > > >
Re: [pygame] vista testing...
ah, cool. Here's a couple of links from a search for more info: http://channel9.msdn.com/Showpost.aspx?postid=211271 http://channel9.msdn.com/Showpost.aspx?postid=209647 http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=463884&SiteID=1 I think it should be fairly straight forward... but I can't seem to find out to actually add the manifest to an exe. Do you know how to add a manifest to an exe? cheers, On Feb 16, 2008 11:29 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > On Vista if a program doesn't have a "manifest" that tells Vista > whether it wants to ask for permissions or not, the default behavior > is for Vista to let it think that it is writing and doing a bunch of > things that would affect all users on XP, but virtualize them in a way > that is per user (and can be lost or wiped as well). The manifest can > tell the OS to either ask for elevation of privilege to let it do > things for all users (the trust box), or to have the app run with > whatever it can get, or to have the app run without special prvileges. > > It sounds like maybe the install has a manifest, but the manifest is > set to not ask to elevate. > > manifests can be modified/added/deleted from finished built exe's as > long as the exe isn't signed, so if you wanted to play around with the > manifest settings you could. > > > On Fri, Feb 15, 2008 at 4:17 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > - the pygame installer brings up a bunch of messages about things it can't > > do... but then manages to install ok. I think it's trying to do things like > > set registry keys, but vista is blocking it. I think this is more the fault > > of the distutils install maker. Anyone know about changes needed for vista > > installers? For most installers vista pops up a message about "do you trust > > this installer". This doesn't happen for the pygame one... so maybe we have > > to ask vista for permission. > > >
Re: [pygame] vista testing...
On Vista if a program doesn't have a "manifest" that tells Vista whether it wants to ask for permissions or not, the default behavior is for Vista to let it think that it is writing and doing a bunch of things that would affect all users on XP, but virtualize them in a way that is per user (and can be lost or wiped as well). The manifest can tell the OS to either ask for elevation of privilege to let it do things for all users (the trust box), or to have the app run with whatever it can get, or to have the app run without special prvileges. It sounds like maybe the install has a manifest, but the manifest is set to not ask to elevate. manifests can be modified/added/deleted from finished built exe's as long as the exe isn't signed, so if you wanted to play around with the manifest settings you could. On Fri, Feb 15, 2008 at 4:17 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > - the pygame installer brings up a bunch of messages about things it can't > do... but then manages to install ok. I think it's trying to do things like > set registry keys, but vista is blocking it. I think this is more the fault > of the distutils install maker. Anyone know about changes needed for vista > installers? For most installers vista pops up a message about "do you trust > this installer". This doesn't happen for the pygame one... so maybe we have > to ask vista for permission. >
