Regarding inability of Python Module Winsound to produce beep in decimal frequency

[jak]

Il 13/08/2021 18:17, Chris Angelico ha scritto:
> On Sat, Aug 14, 2021 at 2:11 AM Terry Reedy <tjreedy at udel.edu> wrote:
>>
>> On 8/13/2021 6:53 AM, Umang Goswami wrote:
>>> Hi There, Hope you find this mail in good health.
>>>
>>> I am Umang Goswami, a Python developer and student working on a huge
>>> project for automation of music instruments. I am producing the musical
>>> notes using the Beep function of Winsound Module(
>>> https://docs.python.org/3/library/winsound.html) by passing frequency as a
>>> argument to the function.
>>>
>>> Now whenever i provide frequency of any note in decimal(for example
>>> 277.1826 for C4 note) it shows following error:
>>> Traceback (most recent call last):
>>>     File "C:\Users\Umang Goswami\Desktop\Umang  Goswami\test.py", line 2, in
>>> <module>
>>>       winsound.Beep(111.11,111111)
>>> TypeError: integer argument expected, got float
>>>
>>> Now I have  to round up the frequencies. This is hurting the quality,
>>> accuracy ,authenticity and future of the project. Almost all the notes have
>>> the frequencies  in decimal parts. Rounding up means changing semitones and
>>> quatertones thus whole note itself. This problem is technically making my
>>> program useless.
>>>
> 
> Is it really? In my experience, no human ear can distinguish 277Hz
> from 277.1826Hz when it's played on a one-bit PC speaker, which the
> Beep function will be using.
> 
> ChrisA
> 

Hi,
you could use a trick to get a better approximation:
277 * 4 = 1108
278 * 1 = 278
1108 + 278 = 1386
1386/5 = 277.2
now, respecting the duration of the tone, in accordance with its simple
rate, the buffer to be played will become:
277, 277, 277, 277, 278, 277,
277, 277, 277, 278, 277, 277,
... and so on.