Recent

Author Topic: Bell for Linux  (Read 5861 times)

winni

  • Hero Member
  • *****
  • Posts: 3197
Bell for Linux
« on: October 10, 2020, 01:55:22 am »
Hi!

We had that topc a lot of times.
And we had a lot of problems.

PC-Speaker is often no more on board - that saves 0.50  € in the production.
The bell is often missing in  Linux.

The hooks are available in sysutils.
We do it like Windows does:
We use the Sound-System.

aplay is the default interface to Alsa and available on (nearly) all Linux distros.

Midnight productions:

I created the stand alone unit beepbeep which only needs its include file
BellString.inc

Put both files in the same directory. No matter if it is a separate directory or
your current project directory.

Add beepbeep to the uses list.

If you are lazy that's all.
With every 'beep' in your code you hear a nice door chime.
If that does not fit your taste you need the only procedure in the interface:

Code: Pascal  [Select][+][-]
  1.  procedure setUserBell( BellWave : string);

To keep the things simple this must be a WAV file.
Now with every beep you hear the sound selected by you.

KDE comes with a lot of WAV files. If you don't have another source.

Ding Dong.

Winni


MarkMLl

  • Hero Member
  • *****
  • Posts: 6685
Re: Bell for Linux
« Reply #1 on: October 10, 2020, 10:33:00 am »
There are three specific cases to be considered.

1) A non-GUI program running on the physical console.

2) A non-GUI program running in a shell session wrapped in xterm, konsole etc.

3) A GUI program.

In the case of (1), WriteLn() etc. with a standard #$07 will work: if it doesn't, it's a distro problem.

In the case of (2), there is no straightforward solution without importing a lot of extra libraries.

In the case of (3), it is reasonable to assume that ALSA is available (although this should not be made a prerequisite for the program to run), and a reasonable fallback position is to use the X11 bell. Both of these use extra libraries, although it's reasonable to expect that they are already available (e.g. a GUI program can be assumed to use X11 or an equivalent).

In the cases of both (2) and (3), consideration needs to be given if the program is being run remotely: SSH or X11 over a LAN: it's highly undesirable for the sound to come from a headless computer (e.g. in a server rack) rather than from the client system near the user.

Also in (2) and (3), it might be worth considering the availability of MIDI if ALSA is to be used directly.

I think I've seen a cut-down ALSA interface which might be less hassle than using alsapas, since it tends to be a bit picky about versions. Is there a standard interface to get an X11 window manager to beep on behalf of an application program?

MarkMLl

MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Bell for Linux
« Reply #2 on: October 10, 2020, 01:23:30 pm »

In the case of (1), WriteLn() etc. with a standard #$07 will work: if it doesn't, it's a distro problem.

MarkMLl

Hi!

#$07 aka BEL relies on the presence of a PC speaker aka buzzer.

The most of the PCs delivered today comes without a "beeper".
As I wrote above.

That's why I made the above unit.

Winni
 

MarkMLl

  • Hero Member
  • *****
  • Posts: 6685
Re: Bell for Linux
« Reply #3 on: October 10, 2020, 01:52:21 pm »
I was summarising the situation. OK, if (1) doesn't work it's a distro problem or a problem in the user's choice of hardware... there's plenty of server computers which could benefit from being able to generate an audio alert but don't have soundcards.

And relying on aplay isn't a good idea, even if a computer has a soundcard and the distro has bundled ALSA with the desktop environment aplay, which in Debian is in alsa-utils, might not be installed.

I'm enthusiastic about the idea of getting this working properly. Blindly calling aplay is NOT the way to do it.

When this was last discussed I added this to some of the stuff I was working on:

Code: [Select]
// Also see https://github.com/tinyalsa/tinyalsa and thread based at
// https://forum.lazarus.freepascal.org/index.php/topic,49502.msg358923.html#msg358923
// which could potentially be a guide to a pure-Pascal ALSA interface which
// communicated with the kernel without needing C-based libraries.
//
// Also http://bulba.untergrund.net/Ay_Emul29b26.src.7z which is a sound-chip
// emulator apparently written in Lazarus.

MarkMLl
« Last Edit: October 10, 2020, 02:05:23 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Bell for Linux
« Reply #4 on: October 10, 2020, 02:01:03 pm »

In the case of (2), there is no straightforward solution without importing a lot of extra libraries.

MarkMLl

Hi!

Also wrong. Just do:

Code: Bash  [Select][+][-]
  1. cat /Windows/C/wav/jingles/pop.wav  | aplay

No extra libs needed. Wrap it into fpc.


The beep command does not work in for me all cases you mentioned above. No beeper.
My solution works on nearly all cases I need.

So it is a big progress.

If you think there is a need for the other cases feel free to add some code to the above unit.

Winni

PascalDragon

  • Hero Member
  • *****
  • Posts: 5469
  • Compiler Developer
Re: Bell for Linux
« Reply #5 on: October 11, 2020, 01:25:32 pm »
Also wrong. Just do:

Code: Bash  [Select][+][-]
  1. cat /Windows/C/wav/jingles/pop.wav  | aplay

No extra libs needed. Wrap it into fpc.

This will only work if the system indeed contains the ALSA userspace utilities.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6685
Re: Bell for Linux
« Reply #6 on: October 11, 2020, 09:32:38 pm »
This will only work if the system indeed contains the ALSA userspace utilities.

Which most distreaux don't by default. The intention is admirable, but we need a minimal way to send a bytestream to the kernel which doesn't rely on an optional program or on alsapas unless that's folded into FPC (which is extremely unlikely to happen).

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Bell for Linux
« Reply #7 on: October 11, 2020, 10:04:40 pm »
Alsa is part of the Linux Kernel since Version 2.6.

It is the default Linux sound system since now over 15 Years.

The userspace utilities are installed by default by a lot of system.
If not they are part of the distro.
No Linux distro without Alsa today.

Keep on trashing .

Winni

MarkMLl

  • Hero Member
  • *****
  • Posts: 6685
Re: Bell for Linux
« Reply #8 on: October 11, 2020, 10:27:56 pm »
Look, this has been discussed before. I agree that ALSA is close to being a standard part of the kernel. I don't agree that an acceptable way to drive it is relying on a program that is not installed as standard.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5469
  • Compiler Developer
Re: Bell for Linux
« Reply #9 on: October 12, 2020, 11:27:29 am »
Alsa is part of the Linux Kernel since Version 2.6.

It is the default Linux sound system since now over 15 Years.

Nobody disputes that.

The userspace utilities are installed by default by a lot of system.
If not they are part of the distro.
No Linux distro without Alsa today.

And that is simply not true. E.g. on Arch I have to install them manually as long as no other package depends on them. And them not being available by default means I (and more generally a general RTL like FPC's) can not rely on them being here. What is likely to be there always (except on very embedded systems without sound support anyways) is the kernel interface.

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Bell for Linux
« Reply #10 on: October 12, 2020, 11:45:29 am »
Hi!

Arch is know to be lean.

Ubuntu, Fedora, Suse,  .... come with preinstalled Alsa userspace utilies.

And along your arguments:

Why does the sysutils come with a beep?
Even if this does not work?
And if I try to make them working:
I cannot rely on the existence of a beeper.
I don't have one on the board.

Your argumentation is inconsistent.

Winni

MarkMLl

  • Hero Member
  • *****
  • Posts: 6685
Re: Bell for Linux
« Reply #11 on: October 12, 2020, 12:35:31 pm »
Debian doesn't.

Look, /somebody/, somewhere, in some language, must have tackled the problem of telling the Linux kernel to make a noise via ALSA without using either a separate program or a heavyweight library. The best I've found so far is a lightweight library in C, I pasted the link earlier.

For /minimal/ use, assuming that the mixer defaults at boot to route sound through to something useful, surely it can't be that complicated. Otherwise is there something at the window manager level (or widget set etc.) to do it? I know that wmctrl doesn't do it, and I don't think that it's in the scope of the xdg utilities... but that's about as far as I've looked.

The ALSA API is ubiquitous, or its absence is easily detected by what's in /dev That's the level that should be used.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Bell for Linux
« Reply #12 on: October 12, 2020, 02:36:22 pm »
At least, if you insist on using an external tool you should check whether it's in fact there (with, say, FileSearch()). Otherwise the end-user might find itself looking at an exception message  which shouldn't have been triggered in the first place.

Note also that, when it works, your solution falls on the other extreme: you now force the user to have a sound card and speakers connected and on. Granted, that might be the usual setup but it isn't certain for all; it's just the same situation as with the "standard" buzzer which is no longer "standard".

And note also that while there might not be a connected buzzer most sound cards are able to mimic it themselves (through hardware or software), which is one reason why the buzzer is no longer physically there most of the time.

Nevertheless it's a tricky situation from whatever point of view, so your "solution" is no worse that so many others (including my own workarounds, btw ;) ).
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Bell for Linux
« Reply #13 on: October 12, 2020, 03:29:10 pm »
Debian doesn't.

MarkMLl

Another nonsense.

Just tested on Squeeze and Buster.
aplay is per default installed.

On Servers which had never anything to do with Sound.


The Debian documentation tells:

execute

aplay -l

to get an overwiew about the hardware.


Waiting for the next lie.

Winni

PascalDragon

  • Hero Member
  • *****
  • Posts: 5469
  • Compiler Developer
Re: Bell for Linux
« Reply #14 on: October 12, 2020, 03:44:24 pm »
Why does the sysutils come with a beep?
Even if this does not work?

The SysUtils unit comes with a Beep routine so that code coming from Delphi compiles correctly. That's all. It's nowhere guaranteed that it works, just like Classes.AllocateHWnd is currently only implemented for i386-win32.

And FPC's RTL strives for cross platform compatibility, that also includes across Linux distributions. Including something that is known not to be the default across the board of distributions and additionally something that requires the execution of an external program is simply not done.

 

TinyPortal © 2005-2018