hi, see this ubuntu bug for a possible fix: https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/216397
There's some debs you can download if you like, but the patches should eventually get into ubuntu. Btw, it's working ok for me, and others on ubuntu. So it's kind of a combination of problems from pygame down to sdl, down to pulse, down to alsa, down to alsa drivers -- but only for some computers and combinations of sound formats. cheers, On Tue, Jul 15, 2008 at 5:31 AM, Gary Bishop <[EMAIL PROTECTED]> wrote: > 1. No, diff. That sleep is just waiting for the audio to terminate. > > 2. Yes, fooling with the options to pygame.mixer.pre_init seems to always be > the not very satisfactory answer. My understanding of the goal for 1.8.1 was > to eliminate that requirement. Having users fool with numbers on a hit or > miss basis is a sure way to drive them away. > > That said, I found that forcing the rate to 44100 instead of letting it be > at 22050 where it apparently went by default makes it sound better. Makes no > sense that a higher sampling rate cures it but it appears to. > > 3. Yes, the real code pumps the event queue. That was just a boiled down > demo case. > > Thanks > gb > > claxo wrote: >> >> I'am not an expert in pygame audio but: >> >> 1. It makes any diference if you reduce the sleep time? Say, 1/30 sec by >> example. >> >> 2. It makes some diference if you initialize the mixer with diferent >> buffer >> sizes ? That was pointed to me by Patrick Mullen time ago, and the advice >> periodically resurfaces. Sometimes, especially with old hardware, >> increasing the buffer size alleviates the problem ( at the cost of more >> latency, If i remember well). >> >> ex: # last param is buffer size pygame.mixer.init(44100, -16, >> True, 1024) >> >> 3. Your real code really dont pump the event queue? Maybe .get_busy() >> updates all necesary inner state, but a lot of pygame functionallity >> depends on the event queue being pumped. >> >> HTH >> >> --- claxo >
