[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Sound still glitchy in 1.8.1rc1 on Ubuntu



Hi,

Yes, I have run the buffer size up huge with no improvement. I'm pretty sure it is not a buffer size problem.

I isolated this piece from some spoken text. It occurred on several words in the sequence but not on every word. It does not appear to be related to amplitude because some words sounded fine at higher and lower volumes. It is not obvious what is different. Particular lengths? Maybe only a few samples are broken and some words have very low energy at those places?

I hear the problem at 11025 as well as 22050. I *don't* hear the problem with the size set to -8 but I don't want to use 8 bit audio.

I wish my sound card had the capability to record the stereo output. Then I could carefully examine the waveform to possibly guess what is happening. Alas, it doesn't. Perhaps a jumper from headphone to microphone will do the job with careful adjustment of the levels.

gb

Brian Fisher wrote:
Hi Gary,
  Making the mixer work great in all cases without tweaking numbers is
indeed a goal for pygame. I would guess that in this case the problem may be
something other than the buffer size, which is what was tweaked in 1.8.1 to
be larger. This seems the case to me because you mentioned a higher sampling
rate eliminates the problem for you.

To confirm, can you try a big fat buffer size with the original 22050
sampling rate? (basically something that should be able to fit the whole .44
second wave without mixing over time)
so something like this:
pygame.mixer.init(22050, -16, 2, 16384)
The lag will likely be longer, so I'm just curious if playback quality is
good in that case.

Also, have you tried many other wav files? Any at different sampling rates?
Is the problem consistent at 22050 for all samples tried, or are there some
that don't seem to have problems?


On Mon, Jul 14, 2008 at 12:31 PM, Gary Bishop <gb@xxxxxxxxxx> wrote:

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.