RE: Regarding inability of Python Module Winsound to produce beep in decimal frequency
-Original Message-
From: Python-list On
Behalf Of Greg Ewing
Sent: Wednesday, August 18, 2021 11:49 AM
To: python-list@python.org
Subject: Re: Regarding inability of Python Module Winsound to produce beep
in decimal frequency
On 18/08/21 4:43 pm, Steve wrote:
>>
>> "The HAL (hardware abstraction layer) function HalMakeBeep()"
>> Is the beep that opens the pod bay doors?
> def HalMakeBeepUsingPCSpeaker():
> raise IOError("I'm sorry, I can't do that, Dave.")
I tried that but all it reported was a very slow:
"Daisy, Daisy, give me your answer do"
And that is when I figured that I knew I should have done that backup
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On 18/08/21 4:43 pm, Steve wrote:
"The HAL (hardware abstraction layer) function HalMakeBeep()"
Is the beep that opens the pod bay doors?
def HalMakeBeepUsingPCSpeaker():
raise IOError("I'm sorry, I can't do that, Dave.")
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
RE: Regarding inability of Python Module Winsound to produce beep in decimal frequency
"The HAL (hardware abstraction layer) function HalMakeBeep()" Is the beep that opens the pod bay doors? Footnote: George Melly remarked to Mike Jagger on how lined his face was for one so young. Jagger replied Theyre laughter lines George to which Melly countered: Mick, nothings that f**king funny!. -Original Message- From: Python-list On Behalf Of Eryk Sun Sent: Tuesday, August 17, 2021 6:23 PM To: Dennis Lee Bieber Cc: python-list@python.org Subject: Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency On 8/17/21, Dennis Lee Bieber wrote: > On Tue, 17 Aug 2021 15:11:05 +1000, Chris Angelico > declaimed the following: > >>Huh. Okay. Then I withdraw the concern from this list, and instead lay >>it at Microsoft's feet. That is, I maintain, a bizarre choice. Surely >>there are better ways to trigger audio on the sound card? > > Possibly there is a section of code that determines if a sound card > is available, and if not, routes to the basic internal speaker. The > rest of the wave form logic is probably still of use for that. It may be that there's a fallback audio device that uses the PC speaker on systems that lack even basic audio support in their chipset. But in common practice, Beep() does not use the PC speaker. The "beep.sys" driver in Windows 7+ has no code path that starts a PC speaker beep via HalMakeBeep(frequency) and ends it after a timeout via HalMakeBeep(0), which was the old implementation of "beep.sys" that can still be seen in ReactOS [1]. The HAL (hardware abstraction layer) function HalMakeBeep() is still implemented in Windows 10, but without the connection to an IOCTL in "\Device\Beep", or some other installed device driver, there's no way for user-mode code to make a beep with the classic PC speaker. In Windows 7+, the beep device's IOCTL_BEEP_SET function is just a relay. It's implemented by searching for and completing a queued IOCTL request from a task in the user's session (i.e. an inverted callback from kernel mode to user mode). This task, which is scheduled to run at logon in every interactive session, executes the "PlaySoundSrv.dll" module in an instance of "taskhostw.exe". Upon completion of its queued IOCTL, from which it gets the beep frequency and duration, the sound server generates the requested beep waveform and plays it on the default audio output device via WinAPI PlaySound(). Notably, the "beep.sys" driver doesn't support manually starting the sound-server task in the user's session. So if one terminates the "taskhostw.exe" process that's hosting "PlaySoundSrv.dll", WinAPI Beep() will no longer work. To get it back, the "\Microsoft\Windows\Multimedia\SystemSoundsService" task has to be restarted manually. --- [1] https://github.com/reactos/reactos/blob/master/drivers/base/beep/beep.c#L295 -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On 8/17/21, Dennis Lee Bieber wrote: > On Tue, 17 Aug 2021 15:11:05 +1000, Chris Angelico > declaimed the following: > >>Huh. Okay. Then I withdraw the concern from this list, and instead lay >>it at Microsoft's feet. That is, I maintain, a bizarre choice. Surely >>there are better ways to trigger audio on the sound card? > > Possibly there is a section of code that determines if a sound card is > available, and if not, routes to the basic internal speaker. The rest of > the wave form logic is probably still of use for that. It may be that there's a fallback audio device that uses the PC speaker on systems that lack even basic audio support in their chipset. But in common practice, Beep() does not use the PC speaker. The "beep.sys" driver in Windows 7+ has no code path that starts a PC speaker beep via HalMakeBeep(frequency) and ends it after a timeout via HalMakeBeep(0), which was the old implementation of "beep.sys" that can still be seen in ReactOS [1]. The HAL (hardware abstraction layer) function HalMakeBeep() is still implemented in Windows 10, but without the connection to an IOCTL in "\Device\Beep", or some other installed device driver, there's no way for user-mode code to make a beep with the classic PC speaker. In Windows 7+, the beep device's IOCTL_BEEP_SET function is just a relay. It's implemented by searching for and completing a queued IOCTL request from a task in the user's session (i.e. an inverted callback from kernel mode to user mode). This task, which is scheduled to run at logon in every interactive session, executes the "PlaySoundSrv.dll" module in an instance of "taskhostw.exe". Upon completion of its queued IOCTL, from which it gets the beep frequency and duration, the sound server generates the requested beep waveform and plays it on the default audio output device via WinAPI PlaySound(). Notably, the "beep.sys" driver doesn't support manually starting the sound-server task in the user's session. So if one terminates the "taskhostw.exe" process that's hosting "PlaySoundSrv.dll", WinAPI Beep() will no longer work. To get it back, the "\Microsoft\Windows\Multimedia\SystemSoundsService" task has to be restarted manually. --- [1] https://github.com/reactos/reactos/blob/master/drivers/base/beep/beep.c#L295 -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On Tue, 17 Aug 2021 15:11:05 +1000, Chris Angelico declaimed the following: > >Huh. Okay. Then I withdraw the concern from this list, and instead lay >it at Microsoft's feet. That is, I maintain, a bizarre choice. Surely >there are better ways to trigger audio on the sound card? > Possibly there is a section of code that determines if a sound card is available, and if not, routes to the basic internal speaker. The rest of the wave form logic is probably still of use for that. -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On Tue, Aug 17, 2021 at 1:50 PM Eryk Sun wrote: > > On 8/16/21, Chris Angelico wrote: > > On Tue, Aug 17, 2021 at 11:44 AM Eryk Sun wrote: > > > >> Yes, the PC speaker beep does not get used in Windows 7+. The beep > >> device object is retained for compatibility, but it redirects the > >> request to a task in the user's session (which could be a remote > >> desktop session) that generates a WAV buffer in memory and plays it > >> via PlaySound(). > > > > That seems a bizarre way to handle it. > > Check the documentation [1]: > > In Windows 7, Beep was rewritten to pass the beep to the default sound > device for the session. This is normally the sound card, except when > run under Terminal Services, in which case the beep is rendered on the > client. > Huh. Okay. Then I withdraw the concern from this list, and instead lay it at Microsoft's feet. That is, I maintain, a bizarre choice. Surely there are better ways to trigger audio on the sound card? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On 8/16/21, Chris Angelico wrote: > On Tue, Aug 17, 2021 at 11:44 AM Eryk Sun wrote: > >> Yes, the PC speaker beep does not get used in Windows 7+. The beep >> device object is retained for compatibility, but it redirects the >> request to a task in the user's session (which could be a remote >> desktop session) that generates a WAV buffer in memory and plays it >> via PlaySound(). > > That seems a bizarre way to handle it. Check the documentation [1]: In Windows 7, Beep was rewritten to pass the beep to the default sound device for the session. This is normally the sound card, except when run under Terminal Services, in which case the beep is rendered on the client. I didn't just take their word for it, however. I checked the code for "\Device\Beep" in a kernel debugger. It gets the session ID to find and complete the I/O Request Packet (IRP) that was queued up by the per-session multimedia task (in Windows device drivers, this is called an inverted call [2]). I attached a debugger to the taskhostw.exe process that's hosting the multimedia task -- in particular the PlaySoundSrv.dll module -- and followed what it did to play a beep. The implementation is in a CBeepRedirector class, in particular its WorkThread() method handles the completed IOCTL from the beep device by calling the DoPlaySound() method, which calls Generate16bitMonoTone() to create a sine wave in WAV format, and plays it via PlaySound() with the SND_MEMORY flag. > multiple sound cards? PlaySound() and system sounds use the default audio output device. If it's an RDP session, the audio is redirected to the client-side device stack. > attention despite headphones being connected to the sound card? An application that wants the user's attention can also flash the window caption and/or taskbar button via FlashWindowEx(). --- [1] https://docs.microsoft.com/en-us/windows/win32/api/utilapiset/nf-utilapiset-beep [2] https://www.osr.com/nt-insider/2013-issue1/inverted-call-model-kmdf -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On Tue, Aug 17, 2021 at 11:44 AM Eryk Sun wrote: > > On 8/16/21, Roel Schroeven wrote: > > > > We're not necessarily talking about the PC speaker here: (almost) all > > computers these days have sound cards (mostly integrated on the > > motherboard) that are much more capable than those one-bit PC speakers. > > Yes, the PC speaker beep does not get used in Windows 7+. The beep > device object is retained for compatibility, but it redirects the > request to a task in the user's session (which could be a remote > desktop session) that generates a WAV buffer in memory and plays it > via PlaySound(). That seems a bizarre way to handle it. What happens if you have multiple sound cards? Or if a program needs to get the user's attention despite headphones being connected to the sound card? That's what the PC speaker is for, and I would be quite surprised if Windows just says "nahh that doesn't matter". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On 8/16/21, Roel Schroeven wrote: > > We're not necessarily talking about the PC speaker here: (almost) all > computers these days have sound cards (mostly integrated on the > motherboard) that are much more capable than those one-bit PC speakers. Yes, the PC speaker beep does not get used in Windows 7+. The beep device object is retained for compatibility, but it redirects the request to a task in the user's session (which could be a remote desktop session) that generates a WAV buffer in memory and plays it via PlaySound(). You can do this yourself if you need a more precise frequency. For example: import io import math import wave import winsound def beep(frequency, duration): '''Play a beep at frequency (hertz) for duration (milliseconds).''' fs = 48000 f = 2 * math.pi * frequency / fs n = round(duration * fs / 1000) b = io.BytesIO() w = wave.Wave_write(b) w.setnchannels(1) w.setsampwidth(2) w.setframerate(fs) w.writeframes(b''.join(round(32767 * math.sin(f*i)).to_bytes( 2, 'little', signed=True) for i in range(n))) w.close() winsound.PlaySound(b.getbuffer(), winsound.SND_MEMORY) Play a beep at 277.1826 Hz for one second: beep(277.1826, 1000) I'm tone deaf, I suppose, since I need a difference of about 3 cycles to perceive it, let alone a fraction of a cycle. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
Il 13/08/2021 18:17, Chris Angelico ha scritto: On Sat, Aug 14, 2021 at 2:11 AM Terry Reedy 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 winsound.Beep(111.11,11) 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
Op 15/08/2021 om 7:01 schreef Chris Angelico: On Sun, Aug 15, 2021 at 1:02 PM John O'Hagan wrote: > > > On 2021-08-13 17:17, Chris Angelico wrote: > > > 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. > > Rounding to integer frequencies will produce disastrously out-of-tune > notes in a musical context! Particularly for low notes, where a whole > semitone is only a couple of Hz difference. Even for higher notes, when > they're played together any inaccuracies are much more apparent. But before you advocate that too hard, check to see the *real* capabilities of a one-bit PC speaker. We're not necessarily talking about the PC speaker here: (almost) all computers these days have sound cards (mostly integrated on the motherboard) that are much more capable than those one-bit PC speakers. Beep uses that sound card, when available. I don't know how accurate the generated sound is though. -- "Now, the invention of the scientific method and science is, I'm sure we'll all agree, the most powerful intellectual idea, the most powerful framework for thinking and investigating and understanding and challenging the world around us that there is, and that it rests on the premise that any idea is there to be attacked and if it withstands the attack then it lives to fight another day and if it doesn't withstand the attack then down it goes. Religion doesn't seem to work like that; it has certain ideas at the heart of it which we call sacred or holy or whatever. That's an idea we're so familiar with, whether we subscribe to it or not, that it's kind of odd to think what it actually means, because really what it means is 'Here is an idea or a notion that you're not allowed to say anything bad about; you're just not. Why not? - because you're not!" -- Douglas Adams -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On Sun, Aug 15, 2021 at 1:03 AM Chris Angelico wrote: > > On Sun, Aug 15, 2021 at 1:02 PM John O'Hagan wrote: > > > > > On 2021-08-13 17:17, Chris Angelico wrote: > > > > 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. > > > > Rounding to integer frequencies will produce disastrously out-of-tune > > notes in a musical context! Particularly for low notes, where a whole > > semitone is only a couple of Hz difference. Even for higher notes, when > > they're played together any inaccuracies are much more apparent. > > But before you advocate that too hard, check to see the *real* > capabilities of a one-bit PC speaker. You go on to give an example > that uses PyAudio and a sine wave, not the timer chip's "beep" > functionality. > > Try getting some recordings of a half dozen or so computers making a > beep at 440Hz. Then do some analysis on the recordings and see whether > they're actually within 1Hz of that. > > (And that's aside from the fact that quite a number of computers will > show up completely silent, due to either not having an internal > speaker, or not letting you use it.) > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list This thread got me curious, and I found this article. The code is very similar to the pyaudio version a few responses back. https://thehackerdiary.wordpress.com/2017/06/09/it-is-ridiculously-easy-to-generate-any-audio-signal-using-python/ except it doesn't need pyaudio I run Ubuntu 20.04, and I had problems getting pyaudio on my machine. -- Joel Goldstick -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On Sun, Aug 15, 2021 at 1:02 PM John O'Hagan wrote: > > > On 2021-08-13 17:17, Chris Angelico wrote: > > > 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. > > Rounding to integer frequencies will produce disastrously out-of-tune > notes in a musical context! Particularly for low notes, where a whole > semitone is only a couple of Hz difference. Even for higher notes, when > they're played together any inaccuracies are much more apparent. But before you advocate that too hard, check to see the *real* capabilities of a one-bit PC speaker. You go on to give an example that uses PyAudio and a sine wave, not the timer chip's "beep" functionality. Try getting some recordings of a half dozen or so computers making a beep at 440Hz. Then do some analysis on the recordings and see whether they're actually within 1Hz of that. (And that's aside from the fact that quite a number of computers will show up completely silent, due to either not having an internal speaker, or not letting you use it.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On Fri, 13 Aug 2021 17:41:05 +0100 MRAB wrote: > On 2021-08-13 17:17, Chris Angelico wrote: > > On Sat, Aug 14, 2021 at 2:11 AM Terry Reedy > > 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 > >> > winsound.Beep(111.11,11) > >> > 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. > > > I've just tried it on my PC and I couldn't hear the difference, > except that odd frequencies had a momentary break in them during > longer notes whereas even frequencies didn't. Very odd... Rounding to integer frequencies will produce disastrously out-of-tune notes in a musical context! Particularly for low notes, where a whole semitone is only a couple of Hz difference. Even for higher notes, when they're played together any inaccuracies are much more apparent. To the OP, there aren't too many options in pure python for playing audio - to do anything complicated I've used applications such as Fluidsynth and sox as python subprocesses. But for playing purely generated tones, here's an example that doesn't limit frequency precision, using pyaudio to play a numpy array representing a sine-wave: import pyaudio, numpy as np f = 555.555 #frequency d = 1.0 # duration in seconds rate = 44100 #sample rate p = pyaudio.PyAudio() stream = p.open(format=pyaudio.paFloat32, channels=1, rate=rate, output=True) samples = np.sin(2*np.pi*np.arange(rate*d)*f/rate).astype(np.float32) stream.write(samples) Hope this helps John -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On 2021-08-13 17:17, Chris Angelico wrote: On Sat, Aug 14, 2021 at 2:11 AM Terry Reedy 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 > > winsound.Beep(111.11,11) > 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. I've just tried it on my PC and I couldn't hear the difference, except that odd frequencies had a momentary break in them during longer notes whereas even frequencies didn't. Very odd... -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
On Sat, Aug 14, 2021 at 2:11 AM Terry Reedy 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 > > > > winsound.Beep(111.11,11) > > 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency
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 winsound.Beep(111.11,11) 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. Its my humble request to you all, I beg you, Please tell me how to overcome this issue. I have consulted many sources both online and offline but I remained unsatisfied. I can not make audio files of each note because there are many many notes and so practically making so many files of different time length wont help. Please suggest to me the way to resolve this issue or is there any other module to produce the sound of decimal frequency. Without knowing what sources you have already looked at, anything anyone might say might be duplication. However,... If the builtin hardware sound generator only generates integral frequencies, you are stuck unless you get an add-in card that is more flexible. If the Windows interface to the hardware only accepts integral frequencies, which I suspect might be true, ditto, unless you get custom software. You could look at pygame and see what its sound functions do. And search pypi for 'sound generator' or 'frequency generator'. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
