Frequency parameter is ignored "pygame.mixer". All values provide same playback. (Not file specfic... but specific to pygame2.0.1 and python3.9 (2435)

[GalacticEmperor1]

Issue №2435 opened by bytefoot at 2021-01-07 10:59:26

Environment:

• Operating system: Windows
• Python version : 3.9.1
• SDL version: 2.0.14
• PyGame version: 2.0.1

Current behavior:
Song plays, but no change in frequency. It is played as orginal audio, in the original frequency itself. Regardless of the value for frequency mentioned in the pygame.mixer.init, the frequency, when played is one and same

Expected behavior:
Song must play with frequency altered according to parameter. It wouldn't sound like played normally

Steps to reproduce:

1. Initialise pygame.mixer with a non-default frequency (eg: 26500, as 44100 is default)
2. Load mp3 file and play it.
3. The song is played at original frequency and not at mentioned frequency
4. Alter the vaule of frequency
5. Still the sound is same and not alteration is observed

Test code

from time import sleep
from pygame import mixer

audio_length = 5.184

mixer.init(frequency=26500)
#  mixer.init()
mixer.music.load("Test.mp3")

mixer.music.play()
sleep(audio_length)
mixer.music.stop()

mixer.quit()

The file "Test.mp3" used in the test code is zipped and attached.
3.9.zip

Key (Strange) Points to Note:

The expected behaviour occurs in:

• Operating system: Windows
• Python version : 3.7.7
• SDL version: 1.2.15
• PyGame version: 1.9.6

In python3.7 as mentioned above, there are no errors and everything works perfectly as expected.
Problem discovered while migrating from python 3.7 to python 3.9.1
Therefore, it can be advised to run the code in python3.7 and 3.9 to note the differences also.

---

Comments

# # robertpfeiffer commented at 2021-01-11 16:33:57

Is playing the song slower really the expected behaviour? I thought the expected behaviour was running the mixing at a lower sampling rate, but the wall clock time would be the same. You mentioned mp3s. Does this work differently with a wav for ogg vorbis file?

---

# # bytefoot commented at 2021-01-12 12:46:06

The expected behaviour is running the mixing at a lower sampling rate. But the error is that the playing of song doesn't change at all... it plays as if the sampling rate gaviven as parameter is ignored.... whatever value i give for kwarg 'frequency'... it plays the same as 44100.

So, I mean to convey that the sampling rate isn't changed/affected though I try to change it using the parameter.

I am currently working with mp3s and that's when i noticed this. I will have check for wav and ogg.

---

# # bytefoot commented at 2021-01-12 13:23:22

12.01.2021_18.48.25_REC.mp4

---

# # MyreMylar commented at 2021-01-12 17:15:35

I wouldn't be surprised if the frequency value only affects pygame Sound objects rather than the streamed music. Generally there are a lot more restrictions on playback of the streamed music (pygame.mixer.music module vs pygame.mixer.Sound) with SDL.

For example, you also can't control the channel on which streamed music plays, or change anything about the reserved music channel.

---

# # bytefoot commented at 2021-01-12 17:25:48

I get your point. But since the sampling rate (frequency kwarg) of the playback is changed and the expected behaviour occurs in the previous version of pygame(1.9.6) and python(3.7), I assumed this to be a bug in the new version(aka pygame2.0.1 and python3.9).

---

# # bytefoot commented at 2021-01-15 15:31:58

I have now checked the mixer with both 'ogg' and 'wav'. The playback is not changed at all. Looks like this problem is not specific to mp3s (ie affects all formats). I guess the mixer's parameters are not actually used. In both, "pygame.mixer.music" and "pygame.mixer.Sound", the value for sampling rate ("frequency" kwarg) doesn't affect playback at all...... Its happens just like in the vid I have commented a few comments before.

I hope I have provided adequate ino... and that this problem may be sorted out at earliest.
(Also, I am going to rename this issue as it is not specific to mp3s, but is a problem of mixer itself.)

---

# # MyreMylar commented at 2021-01-16 17:00:47

@cyberGhoulK First up. I just tried the test program you provided in a fairly recent version of pygame (roughly 2.1 but it's my local copy) and the mp3 playback does distort as I would expect when I change the frequency values to some low input values on my windows PC.

e.g.

from time import sleep
from pygame import mixer

audio_length = 5.184

mixer.init(frequency=1100)
#  mixer.init()
mixer.music.load("Test.mp3")

mixer.music.play()
sleep(audio_length)
mixer.music.stop()

mixer.quit()

This sounds very distorted on my PC. I think your original input value was not low enough for SDL 2 to distort the audio you input.

It's worth noting that SDL 2 doesn't provide any guarantee that the audio device will support the frequency you request. Essentially the way it works now is that you ask for a specific frequency and then the function returns what you actually get from the hardware. I don't think this was ever intended to be used to pitch shift individual sound files as frequency values set here would affect all the audio from an application. Instead this value was intended to set an 'audio quality level' for the whole app for memory/file size saving purposes that are not really as relevant in 2021.

The function being used (eventually and via SDL_Mixer) is:

https://wiki.libsdl.org/SDL_OpenAudioDevice

I tried tracking the frequency numbers through the pygame code with print statements until it disappears into SDL and you can see that pygame does provide the value set in mixer.init() to this function so I don't think this is a bug in pygame's usage of SDL specifically, it seems more likely from my investigations that there has been a change in the way the frequency parameter works in SDL 2.0 vs SDL 1.0.

What it seems that you really want in the SDL 2 world is a pitch shifting mixer effect like this one:

https://gist.github.com/hydren/ea794e65e95c7713c00c88f74b71f8b1

Added to pygame's mixer module, which sounds like a fairly large job - but it would allow you to change the pitch for different audio channels for a set time, rather than for all the audio in an app.

Not much of an audio/SDL_Mixer guy though myself so I could have it wrong.

---

# # bytefoot commented at 2021-01-18 10:10:53

Thank you for investigating into it. Even I have tried what you said, and noticed that a very low frequency does distort the audio, but not in the way as before. So, the bug was not in pygame afterall. Pitch shifting was definetely what I was looking for and thats when I came across pygame.

The new feature (if added) would definetely prove extremely helpful. I wish I could contribute, but I don't know C. Fingers crossed for the pitch shifting.

PS, Should I keep this issue open until the new feature is added, or shall I close it?

---

# # robertpfeiffer commented at 2021-01-19 07:37:47

If you want to play a waveform back slower, or faster, you can do so by generating a re-sampled version of it with sndarray and numpy. Doing this in pure Python won't be fast enough for real time audio, so don't expect to use this in some kind of synthesizer or rhythm game, but if you create distorted versions of sounds during import/on level load/when the user presses a button, you can show am hourglass while you process the audio, and create a cached sound effect you can play back later.

---

# # robertpfeiffer commented at 2021-01-19 07:39:43

@MyreMylar Does setting a low sampling rate actually play the audio back slower, or does it just filter out the high frequencies?

---

# # bytefoot commented at 2021-01-19 13:30:37

@robertpfeiffer Ok thanks. I have already tried numpy and sndarray. As you said, it wasn't fast enough for real time audio. I will look up on the caching part.
And yes, setting a low sample rate plays the audio slower, and the pitch also decreases along with it (to a lesser extent than that of speed). I was actually trying to increase the sample rate in my project.

---

# # kotrenn commented at 2021-11-19 08:11:07

I'm having a similar issue on my end after updating python + pygame.

Currently it appears the frequency variable of pygame.init() has no effect, as when I query for the frequency with pygame.mixer.get_init(), it always returns 48000. This is with pygame 2.1.0, SDL 2.0.16, and Python 3.10.0.

In contrast, when using my older version the frequency returned by get_init() matches what I had set in init(). This is with pygame 1.9.6 and Python 3.8.6rc1.

---

# # Starbuck5 commented at 2021-11-19 08:48:46

@kotrenn see # 2852

---

# # kotrenn commented at 2021-11-19 21:36:44

@Starbuck5 This did fix the issue of pygame.mixer.get_init() not returning the correct value. However, the playback of the music and sound still does not change as it did in pygame 1.9.6.

---

# # g-mac commented at 2022-10-27 09:23:53

Any updates on this?
I am still facing the same issue:

pygame 2.1.2 (SDL 2.0.18, Python 3.7.3)

from pygame import mixer

mixer.init(frequency=22050) #  mp3 is @ 44100 sample rate
mixer.music.load("track.mp3")
mixer.music.play()

result: the playback of the track sounds exactly the same, no matter the value of the frequency.
by the way: print(mixer.get_init()) prints (22050, -16, 2) so that seems to work fine.

Would be great to get the original functionality back, i.e. the ability to pitch down, naturally, by changing the playback frequency. Can we expect this behaviour to come back?

Thanks a lot

[MyreMylar]

The last comment here seems to suggest that with SDL3 and its underlying SDL_AudioStream we may eventually be able to get support for pitch shifting/frequency tinkering into SDL_Mixer and then into pygame-ce.