Hi All,

I am looking for a simple sound beeping component which will produce a tone through the default sound system e.g. a Tone at frequency (in Hertz) for duration MSecs (milliseconds).

It will replace the TbtBeeper (Delphi 5) component which mainly consists of the following procedure:

procedure TbtBeeper.BeepFor(Tone: Word; MSecs: DWORD);
e.g. BeepFor( 100, 500 );
// beep at 100 Hertz for half a second.

Best Regards,
PEW
Hobart, Tasmania, Australia

You cant get a resolution of milliseconds in a user program.

So I would create a wave file that contains the correct "bleep".

With Delphi I once used this wave player component: http://www.un4seen.com/. I don't know if it's been tested with Lazarus and if something similar can be done on Linux.

I used some free tool to create sine and similar waves in wav-files.

-Michael

Hi Michael and All,

Actually I don't need a resolution of single milliseconds. I really only need tens or even hundreds of milliseconds. Typical MSecs parameter is 100ms. Also, exact Tone frequency is not required... only the approx frequency tone. Obviously, since I want to create a range of tones then creating custom wave files would be overkill.

The original TBeeper component for Delphi simply beeped the pc speaker and used some assembler code, but it was only 26KB of code. It also had the ability to play simple tone 'songs' by beeping a range of tone frequencies at different durations. These 'songs' were simply ASCII text data files. I still have it if you are interested.

Best Regards,
PEW
Hobart, Tasmania, Australia

Lol, I wrote something like that years ago... but in these days it was allowed to address the speaker hardware...

Windows.Beep(freq,duration) does about the same, but afaik it is not implemented in Lazarus.

sri,
John

Michael Schnell wrote

?You cant get a resolution of milliseconds in a user program.

Actually in my experience if you check EpikTimer in a loop with a 0-timed sleep you will get millisecond resolution: http://wiki.freepascal.org/EpikTimer

Of course it isn't 100% guaranteed to keep the resolution because it isn't a real-time-system, but in my experience this was more then enough to drive hardware which requires interactions of the order of miliseconds.

At the risk of asking a silly question. Why has no-one ported the Windows.Beep procedure to Lazarus. Surely it is not too hard ?!?

Personally, I like this simple method of basic speaker sounds and I use it with a boolean variable called 'want_sounds' which I let the user toggle via a Tmenuitem (part of a Tmainmenu of the form). I find that this works well and keeps happy users who don't want sound effects. I also write & read this setting to an .ini file, which is simple and saves the user's choice.

Would someone please investigate porting the Windows.Beep procedure to lazarus. I can convert the remainder of the TBeeper.pas unit to Lazarus ... and I think that it would be popular (in limited circles).

Best Regards,
PEW
Hobart, Tasmania, Australia

It's not fool proof, but it's not too hard. See here:

http://github.com/johnath/beep/blob/master/beep.c

Henry

It's not only not fool proof, but beep also requires to be run as root, because a normal user can't open /dev/console with write access.

Regards,
Sven

http://github.com/johnath/beep/blob/master/README#L25

Sorry, sent by mistake. I meant to add that Debian's beep is setuid to get around this (information in readme).

Henry

It might be the case on Debian, but it might not be on other distros and is for sure not on ArchLinux.

Also, if you want beeps in your own program you either need to
- implement beep.c in Pascal (con: you have the same troubles as beep, mentioned in the link you sent)
- use beep with TProcess (con: beep must be installed or included with your app and also needs to be set up correctly)

Regards,
Sven

Peter E Williams wrote

Would someone please investigate porting the Windows.Beep procedure to lazarus. I can convert the remainder of the TBeeper.pas unit to Lazarus ... and I think that it would be popular (in limited circles).

Please consider that in principle at least Lazarus and FPC are portable, and that to meet that requirement it's necessary to consider cases where the user is sitting at a screen that's some distance from the computer running his code. Cue discussion of X, VNC and comparable technology here.

At this point you have to consider whether the noise is going to come out of a squeaker in front of the user, or in the computer itself.

In the former case there is nothing in ASCII or any of the mainstream protocols which defines the properties of the beep.

In the latter case do you intend to use the mainboard's squeaker, the soundcard's DSP, or an attached MIDI device? What do you intend to do if somebody is already using one of these- you could be somewhat less than popular if somebody's attempt to transfer black vinyl to .wav failed because you'd grabbed the DSP.

come one, folks... PEW is a game writer... games beep... why give him so much grief about simply beeping the console's mainboard speaker?? it shouldn't be that hard...

@PEW: how does your game install? does it have to install as root? if so, since it is root, why not set up a new group that has access to the /dev device for the speaker and add the user(s) to it? that way everyone can beep when needed...

come one, folks... PEW is a game writer... games beep...

No, they do not. Only shitty games beep. Decent ones use the sound hardware.

R.

+1

you have such a pleasant attitude...

waldo kitty wrote

@PEW: how does your game install? does it have to install as root? if so, since it is root, why not set up a new group that has access to the /dev device for the speaker and add the user(s) to it? that way everyone can beep when needed...

I'd prefer a game NOT to fiddle around with security settings it hasn't to care about. And /dev/console is definitely part of this.

Regards,
Sven

On Fri, 03 Sep 2010 13:32:49 -0400, waldo kitty wrote about Re: [Lazarus] How to produce a tone at Tone frequency for duration MSecs (milliseconds):

Well, I can offer some code that could keep both points of view satisfied.

I have a unit, specific to Linux, that will allow a program to beep in a suitably disgusting manner that will keep retro-gamers feeling nostalgic for MS-DOS, but using the modern sound hardware. It does not require root privileges either.

Anybody interested?

while i agree... i'm also as old school as PEW and i don't agree to a point or several, actually... one of those being why is the beep action so looked down on in the *nix environment? games started off with only the MB speaker as the way of sounding actions and activities... so what's the bitch problem? is everyone these days so freakin' spoilt by traditional sound card stuff that they refuse to recognize traditional MB speaker sounds? i mean geez, does the standard (k)ubuntu solitaire really use the sound card when sounds are necessary? or the oriental tile games? or the many other single player local console games?

so please tell me why today's folk are so jaundiced to the traditional methods of game writing... surely it isn't due to ignorance... maybe it is due to too much perceived character of their own person?? i dunno... but it is rather ugly, distant and hateful...

Don't get me wrong here. I've nothing against beeping applications. I'm using beep myself to signal when my headless computer has finished booting. And I love old DOS games that beep around as if there's no tomorrow :D

The problem is that the beep "control interface" on *nix platforms seems to be integrated into the terminal system. And I don't want any application to fiddle around with the settings of the devices that belong to that system (especially without my knowledge). Better would be if there'd be a beep device (e.g. /dev/beep) which could be owned by a group "beep" or maybe the existing "audio" group and thus all would be happy...

Regards,
Sven

I can play music over my pc speaker through pulseaudio, so surely it's possible directly with alsa? I may be way off, here, since I usually block the pc speaker module from loading.

while i agree... i'm also as old school as PEW and i don't agree to a point or several, actually... one of those being why is the beep action so looked down on in the *nix environment?

Requiring root to beep is just not acceptable.
Audio hardware can be accessed via an API (ALSA, PulseAudio, OSS, portaudio, etc.) and by group audio, which is far better.

games started off with only the MB speaker as the way of sounding actions and activities... so what's the bitch problem? is everyone these days so freakin' spoilt by traditional sound card stuff that they refuse to recognize traditional MB speaker sounds?

Yes, because a PC is not a pong console and the PC-speaker sound is torture. I just don't like games that sound like a bios failure. Perhaps it has something to do with me starting coding on a computer that had better sound hardware than a PC-speaker (an Atari 130 XE in 1987).

so please tell me why today's folk are so jaundiced to the traditional methods of game writing...

I don't know. I don't feel like today's folk, more like yesterdays folk. :) I am just not that nostalgic that I don't see that hardware and coding has moved on in the 23 years I am doing it. But the real problem (as others have stated, too) is the root access. Without that noone would care if you beep or not. There is just no proper way to use the PC-speaker in Linux.

R.

On Sat, 4 Sep 2010 15:34:04 +0200
Reimar Grabowski wrote:

Small addition:

http://sourceforge.net/projects/humus/ (project includes freepascal bindings for portaudio - portaudio is multi-platform)

http://www.portaudio.com/trac/browser/portaudio/branches/v19-devel/test/patest_sine.c?rev=1097 (simple and short C example code to play a sine wave with portaudio)

hih
R.

http://sourceforge.net/projects/humus/ (project includes freepascal bindings for portaudio - portaudio is multi-platform)

Sorry for replying to myself again.
I just tested the bindings and they worked out of the box on Ubuntu 10.04 64-bit for me. If you do not have portaudio already installed just install portaudio19-dev. The bindings include a simple test program (testpasine.pas) which can be easily modified to provide the desired functionality.

hih
R.

Something like a soundcard has a well-defined interface to the rest of the computer: a set of I/O ports, and potentially DMA capabilities.

An onboard squeaker, /particularly/ on a PC, uses a small part of a chip that's also critical to the operation of the rest of the system. And that, I suspect, is why direct access to it is restricted.

Now it might be that other architectures, original Macs as a particular example, don't have a separate beeper but only a fully-functional sound generator. In which case there's no longer an issue: use ALSA or whatever.

Hello Lazarus-List,

Monday, September 6, 2010, 9:52:21 AM, you wrote:

MML> An onboard squeaker, /particularly/ on a PC, uses a small part of a chip MML> that's also critical to the operation of the rest of the system. And MML> that, I suspect, is why direct access to it is restricted.

Not so critical as it has been removed from modern PCs :) 8254 is being removed by motherboard designers, and beep facility is being routed to sound card via operative system.

More detailed explain for windows:

http://blogs.msdn.com/b/larryosterman/archive/2010/01/04/what-s-up-with-the-beep-driver-in-windows-7.aspx

not to mention that that functionality (Beep(freq, duration)) on a PC speaker requires acces to both the PIT (timer/clock) chip and the 'speaker' as well as that it requires interrupt programming.

(as I recall it)

apart from those lowlevel system-requirements that aren't open to everyone except maybe on DOS, you have to account for the fact that on *nix or in fact any other OS besides DOS, the user isn't necessarily on the same computer as the one where the app runs.

kind regards,
Dimitri Smits