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
