Lazarus

Programming => Operating Systems => Linux => Topic started by: winni on October 10, 2020, 01:55:22 am

Title: Bell for Linux
Post by: winni 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

Title: Re: Bell for Linux
Post by: MarkMLl 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

Title: Re: Bell for Linux
Post by: winni on October 10, 2020, 01:23:30 pm

Quote from: MarkMLl on October 10, 2020, 10:33:00 am

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
 

Title: Re: Bell for Linux
Post by: MarkMLl 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

Title: Re: Bell for Linux
Post by: winni on October 10, 2020, 02:01:03 pm

Quote from: MarkMLl on October 10, 2020, 10:33:00 am

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

Title: Re: Bell for Linux
Post by: PascalDragon on October 11, 2020, 01:25:32 pm

Quote from: winni on October 10, 2020, 02:01:03 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.

Title: Re: Bell for Linux
Post by: MarkMLl on October 11, 2020, 09:32:38 pm

Quote from: PascalDragon on October 11, 2020, 01:25:32 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

Title: Re: Bell for Linux
Post by: winni 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

Title: Re: Bell for Linux
Post by: MarkMLl 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

Title: Re: Bell for Linux
Post by: PascalDragon on October 12, 2020, 11:27:29 am

Quote from: winni 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.

Nobody disputes that.

Quote from: winni on October 11, 2020, 10:04:40 pm

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.

Title: Re: Bell for Linux
Post by: winni 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

Title: Re: Bell for Linux
Post by: MarkMLl 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

Title: Re: Bell for Linux
Post by: lucamar 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 ;) ).

Title: Re: Bell for Linux
Post by: winni on October 12, 2020, 03:29:10 pm

Quote from: MarkMLl on October 12, 2020, 12:35:31 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

Title: Re: Bell for Linux
Post by: PascalDragon on October 12, 2020, 03:44:24 pm

Quote from: winni on October 12, 2020, 11:45:29 am

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.

Title: Re: Bell for Linux
Post by: MarkMLl on October 12, 2020, 04:13:25 pm

Quote from: winni on October 12, 2020, 03:29:10 pm

Another nonsense.
...
Waiting for the next lie.

I would suggest that it is inappropriate to use such language during debate.

As a courtesy to other members of the forum, and to indicate that I, for one, am interested in resolving this with the minimum of name-calling:

An installation of Debian "Stretch" (oldstable) without a GUI but with enough sound support (ALSA/OSS) to support Qemu instances does have aplay.

An installation of Debian "Buster" (stable) with both GUI and sound support sufficient for Qemu does have aplay.

An installation of Debian "Stretch" sufficient to run a wiki server does not have aplay. In the interest of full and fair disclosure, this is running in a VM but was installed from a standard CD.

An installation of Debian "Stretch" sufficient to run Lazarus over SSH (and regularly used for that) does not have aplay. Again for the sake of fairness, that one is running in a Docker container and was largely installed manually, it does not have KDE etc.

Now I log this stuff fairly thoroughly, but can't conclusively say at what point during installation aplay (etc.) is added. My suspicion would be it is as part of a desktop environment, which in my case is usually KDE.

But you do not need a desktop environment to use Lazarus or run Lazarus-built programs, since they can be mapped over ssh (or potentially via VNC etc.) in which case blithely beeping the server would be unhelpful- as I previously noted.

@Winni: So I'd very much appreciate a bit less of the name-calling, particularly when it turns out that you're not entirely in command of the facts.

MarkMLl

Title: Re: Bell for Linux
Post by: winni on October 12, 2020, 07:50:28 pm

Hi!

Just intalled Debian 10.6 in a virtual box.

The very small and basic CD Version with xcfe.
Only 696 MB in the file

debian-10.6.0-amd64-xfce-CD-1.iso

I did not allow to draw further packets via net.
I did not install some extra packages.

The result: At the first start aplay is present.
Like I knew it from all the versions before.
If you don't believe it:
Have a look at the screenshot.

And  if you don't like the word "lies" then do it like the White House:
call it "alternative facts"

Winni

Title: Re: Bell for Linux
Post by: MarkMLl on October 12, 2020, 08:33:45 pm

Quote from: winni on October 12, 2020, 07:50:28 pm

Just intalled Debian 10.6 in a virtual box.

The very small and basic CD Version with xcfe.

Now try it without xfce.

Quote

And  if you don't like the word "lies" then do it like the White House:
call it "alternative facts"

I can assure you that I hold you in higher esteem than I do the current incumbent of the White House.

MarkMLl

Title: Re: Bell for Linux
Post by: MarkMLl on October 22, 2020, 10:48:25 pm

I meant to take another look at this a few days ago, my apologies for the delay particularly to OP on account of my being critical of his approach.

I note that https://www.gnu.org/software/emacs/manual/html_node/elisp/Desktop-Notifications.html has

Quote

:sound-name name
  A themable named sound from the freedesktop.org sound naming specification from ‘$XDG_DATA_DIRS/sounds’, to play when the notification pops up. Similar to the icon name, only for sounds. An example would be ‘"message-new-instant"’.

Now granted that that relates to Emacs, but it appears to be based on D-Bus and on resources governed by xdg doctrine. I've not yet worked out exactly what message content is required, but I think it would be interesting to explore whether unix-based widget sets universally implement an entry point for message injection, in which case using this would almost certainly be preferable to running a program which played a noise from a file.

MarkMLl

Title: Re: Bell for Linux
Post by: Fred vS on October 23, 2020, 01:06:59 am

You may also use only library libasound.so that should be installed in lot of distros.

And use fpc to load/use the methods to produce a sine-wave or random chunks.

http://www.equalarea.com/paul/alsa-audio.html#playex

Title: Re: Bell for Linux
Post by: winni on October 23, 2020, 01:50:05 am

@Fred vS

Hi!

MarkMLI does not like that.

I tried to convince him to Alsa, but he gave me the hint tom reduce Debian until there is no more Alsa in the  distro. From above:

Now try it without xfce.

🙊🙉🙈

Yes, we throw Alsa out.
Next we throw the whole network stuff out, that there is not so much nonsense is spread over the net.
And finaly we throw the kernel out so this bloody Linux does not work anymore.

Okay - a magic way to get rid of Alsa.

Winni

Title: Re: Bell for Linux
Post by: Fred vS on October 23, 2020, 02:16:13 am

@ Winni.

I think that MarkMLI is ok to try to access directly the sound card, without any help of root libraries.

But imho, even if it is possible to not use libasound.so to produce sound, I fear that it would need other library that maybe is less common than libasound.so.

That said, if MarkMLI find a way to access directly the alsa-kernel, wow.

[EDIT]

Quote

Now try it without xfce.

I dont know what Debian version because all include libasound.so (see package file of each version, in particular the standard):

https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/

And from:
https://unix.stackexchange.com/questions/87182/whats-the-difference-between-debian-standard-and-gnome/203328

Debian Live Standard is Debian without the Graphical User Interface.

But libasound.so is included.

Title: Re: Bell for Linux
Post by: MarkMLl on October 23, 2020, 09:10:54 am

"Cutting the crap" as they say". Before anything else, I'd stress that I am not a core developer and would not presume to make decisions on their behalf.

I did not say that we should not rely on libasound.so, but I haven't checked how prevalent that is i.e. whether it goes onto all systems irrespective of configuration. I'll try to do so later today.

What I /have/ said is that I think it is wrong to rely on aplay from (in the Debian case) alsa-utils since it is not universally installed.

I've also said that I think it's regrettable that the existing alsapas library is so heavyweight, if all we need to do is a simple beep. I've expressed surprise that for something this simple there's not a comparatively simple kernel interface.

I've not found anything in e.g. wmctrl to sound a beep. There does however appear to be related functionality exposed via D-Bus, and I would suspect that this is the way to go.

MarkMLl

Title: Re: Bell for Linux
Post by: MarkMLl on October 23, 2020, 12:08:28 pm

It looks as though libasound.so (strictly, something like libasound.so.2.0.0 symlinked as libasound.so.2) is installed on a system which has enough libraries etc. to run the development IDE (in the case I'm looking at it's a Docker container) or on a system with enough libraries to handle audio coming from a Qemu instance. Debian ships it in the libasound2 package, and in general it looks pretty pervasive.

I think it would be highly desirable to not use the full alsapas libraries to access this, since they tend to be rather cumbersome. It would be desirable to go direct to the kernel, but my experience is that there are some kernel interfaces where using anything other than the same compiler is unrealistic so we're probably stuck with libasound unless anything more appropriate is available via e.g. D-Bus.

I believe that I can see KDE's Konsole, as one specific example, using a D-Bus message for sound, but haven't worked out how to trace the content adequately. Also I don't know whether there's a generic way that a widget set can raise such a thing.

MarkMLl

Title: Re: Bell for Linux
Post by: Fred vS on October 23, 2020, 01:23:02 pm

Quote

I think it would be highly desirable to not use the full alsapas libraries to access this,

You may only use the pascal translation of the C header of libasound, nothing more.

But if you can produce beep via dbus, please show us.

Peace.

Fre;D

Title: Re: Bell for Linux
Post by: PascalDragon on October 23, 2020, 02:42:10 pm

The SysUtils unit will not rely on libasound or on executing any external problem. This is not negotiable.

What is however possible is a unit (or multiple, different units) that sets up the OnBeep callback to something more sophisticated and can be used by those users that want (and need) it. This way they have more control over the dependencies.

Title: Re: Bell for Linux
Post by: MarkMLl on October 23, 2020, 03:07:36 pm

How about https://wiki.archlinux.org/index.php/Desktop_notifications ? I think it would rely on the user setting up the desktop environment to beep on receipt of a particular notification though, which would be beyond many.

MarkMLl

Title: Re: Bell for Linux
Post by: Fred vS on October 23, 2020, 04:05:17 pm

Quote from: MarkMLl on October 23, 2020, 03:07:36 pm

How about https://wiki.archlinux.org/index.php/Desktop_notifications ? I think it would rely on the user setting up the desktop environment to beep on receipt of a particular notification though, which would be beyond many.

MarkMLl

Good idea but this is working only on desktop environment.

Imho, like for libasound, it is not enough "root" for SysUtils.

But maybe create a lcl_beep that is part of the lcl packages.

Title: Re: Bell for Linux
Post by: MarkMLl on October 23, 2020, 04:29:11 pm

OTOH the description of Beep() in the RTL is that it's basically a hook configured at runtime... at which point I suppose even Wini's suggestion of aplay could be used however much I dislike it.

I need to go out. The libnotify link points to an example in FPC which itself has a link to a binding on Github. I can see that Konsole and the KDE setup can configure how the desktop handles e.g.  echo -ne '\a'  What I can't work out is how to get the "true name" of the Konsole notification events and relate them to libnotify... if anybody could work that out I'd say we'd just about have the problem licked.

(Sigh) It's all a great deal of hassle when compared with the simple linkage used to ring the bell on a printing terminal... brass on a Teletype, steel on those Olivetti monsters.

MarkMLl

Title: Re: Bell for Linux
Post by: Fred vS on October 23, 2020, 04:45:39 pm

Quote from: MarkMLl on October 23, 2020, 04:29:11 pm

I suppose even Wini's suggestion of aplay could be used

Imho, the Winni's suggestion to use aplay executable or libasound library is more "universal" than notification-daemon package.

But in this case I would prefer to play a custom sine-wave vs load+play a external audio file.

All that said, you may also use uos, it uses Portaudio library that is also included in many all Linux distro.

But this is a other story.

 :)

Fre;D

Title: Re: Bell for Linux
Post by: MarkMLl on October 23, 2020, 04:52:26 pm

I've got nothing against libasound with a concise shim, it was running a secondary program (aplay) that I very much disliked. I was assuming that libasound- at least until one started considering codecs etc.- was itself a comparatively thin layer on top of the kernel.

I agree that using a sine wave as the parameter would be ideal, since apart from anything else that would be in the spirit of the original Beep() from TP etc.

Having said which, the "right way" is probably to use libnotify so that it works properly with the desktop's configuration stuff, and the associated daemon/backend seems to be widely adopted.

MarkMLl

Title: Re: Bell for Linux
Post by: Fred vS on October 23, 2020, 05:33:55 pm

Quote from: MarkMLl on October 23, 2020, 04:52:26 pm

Having said which, the "right way" is probably to use libnotify so that it works properly with the desktop's configuration stuff, and the associated daemon/backend seems to be widely adopted.

Hum, the combat will be hard.

I did check in the debian-standard.packages (distro without GUI) and indeed notification-daemon is also included, like libasound package.

So both dont need extra-installation of packages.

So we all wait for your notification-daemon solution to have something concrete to compare.

 O:-)

Title: Re: Bell for Linux
Post by: MarkMLl on October 23, 2020, 06:37:27 pm

I think a lot depends on whether the community prefers to have Beep()  be /strictly/ a PC-style beep, or prefer it to be the early-C21st equivalent configurable by thematicisation etc.

If Beep() took parameters specifying frequency and duration I'd definitely lean towards the former. It doesn't, so generally speaking I lean towards the latter.

I notice that the messages used by KDE Konsole are variously described as "Bell in Focussed Session" and "Bell in Non-Focussed Session"

If anybody has any familiarity with the actual messages (via D-Bus or whatever) involved please say since I'm having trouble pulling things together.

MaekMLl

Title: Re: Bell for Linux
Post by: PascalDragon on October 23, 2020, 10:22:29 pm

Quote from: MarkMLl on October 23, 2020, 06:37:27 pm

I think a lot depends on whether the community prefers to have Beep()  be /strictly/ a PC-style beep, or prefer it to be the early-C21st equivalent configurable by thematicisation etc.

On Windows beep uses MessageBeep(0) which simply plays back the default Windows beep sound (see here (https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messagebeep)). So the output itself does not need to be “PC-style beep”.

Quote from: MarkMLl on October 23, 2020, 06:37:27 pm

If Beep() took parameters specifying frequency and duration I'd definitely lean towards the former. It doesn't, so generally speaking I lean towards the latter.

The purpose of Beep is simply an acoustic notification of the user.

Title: Re: Bell for Linux
Post by: MarkMLl on October 25, 2020, 10:27:19 am

If a program is started from a shell running in e.g. KDE Konsole and if that has been told to honour the ASCII bell control character, then a simple  Write(#$07)  will result in a sound controlled by the desktop environment's thematicisation.

I was hoping that there would be a way of getting themed control using either libnotify or wmctrl, but so far have had no success. libnotify is oriented towards displaying an alert panel, it can in principle specify a sound name as a hint, but people who definitely wanted an audible alert in a script file were using both send-notify (client to libnotify) and aplay or similar.

General investigation suggests that while aplay is not universally installed, libasound is... at least on systems which purport to be general-purpose. The alsapas libraries are excessively cumbersome for generating a simple beep, and elsewhere it is noted that alsapas includes stuff which varies by ALSA version... I'm already at the position of having to use Docker to generate a binary for one particular server since the ALSA version is different from most of what I'm running around here.

Robert Rozee's approach at https://forum.lazarus.freepascal.org/index.php/topic,49502.msg359352.html?PHPSESSID=ju53vbrr54cosmk03869a2i6r2#msg359352 appears to work, I'm currently converting it from static to dynamic linkage so that it doesn't force a program to have a hard dependency on libasound.

It would probably be desirable for a GUI app to check whether it has a stdout and has Konsole etc. as a parent, and if those conditions were met to use  Write(#$07)  since this will output themed (or no) sound as selected by the user, and will interact with any notification hooks he has set up. I've not yet worked out a reliable way to do this, and suspect that it might depend on the desktop environment installed (i.e. KDE vs Gnome etc.).

MarkMLl

Title: Re: Bell for Linux
Post by: MarkMLl on October 28, 2020, 12:28:03 pm

This discussion ended up being continued at https://forum.lazarus.freepascal.org/index.php/topic,49502.msg382109.html#msg382109

As stated there a dynamically-linked version of work by various people went to Mantis but was rejected. I offer no comment other than to hope that the code turns out useful to various people.

In actual fact somebody has pointed out libcanberra on Linux as a themed sound generator. I'm trying to determine to what extent it is useful.

Later: As usual, the most useful description comes from Arch Linux https://wiki.archlinux.org/index.php/Libcanberra which includes examples. On Debian canberra-gtk-play comes from gnome-session-canberra which doesn't have heavyweight dependencies, and I can confirm that a command line

$ canberra-gtk-play -i KDE-Sys-App-Message

works subject the the existence of /usr/share/sounds/KDE-Sys-App-Message.ogg

However while this does appear to interact sensibly with the theme configuration it's hardly transparent since the names of the various sounds are not easily determined, and also the overhead of converting from a .ogg file strikes me as almost as undesirable as explicitly invoking something like the aplay binary.

MarkMLl