Recent

Author Topic: Bell for Linux  (Read 1761 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: Bell for Linux
« Reply #15 on: October 12, 2020, 04:13:25 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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

winni

  • Hero Member
  • *****
  • Posts: 2000
Re: Bell for Linux
« Reply #16 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


MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: Bell for Linux
« Reply #17 on: October 12, 2020, 08:33:45 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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: Bell for Linux
« Reply #18 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

Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

Fred vS

  • Hero Member
  • *****
  • Posts: 1983
    • StrumPract is the musicians best friend
Re: Bell for Linux
« Reply #19 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
« Last Edit: October 23, 2020, 01:39:32 am by Fred vS »
I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs
https://gitlab.com/fredvs

winni

  • Hero Member
  • *****
  • Posts: 2000
Re: Bell for Linux
« Reply #20 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

« Last Edit: October 23, 2020, 01:53:35 am by winni »

Fred vS

  • Hero Member
  • *****
  • Posts: 1983
    • StrumPract is the musicians best friend
Re: Bell for Linux
« Reply #21 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.
« Last Edit: October 23, 2020, 02:48:58 am by Fred vS »
I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs
https://gitlab.com/fredvs

MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: Bell for Linux
« Reply #22 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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: Bell for Linux
« Reply #23 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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

Fred vS

  • Hero Member
  • *****
  • Posts: 1983
    • StrumPract is the musicians best friend
Re: Bell for Linux
« Reply #24 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
I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs
https://gitlab.com/fredvs

PascalDragon

  • Hero Member
  • *****
  • Posts: 2418
  • Compiler Developer
Re: Bell for Linux
« Reply #25 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.

MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: Bell for Linux
« Reply #26 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
« Last Edit: October 23, 2020, 03:09:38 pm by MarkMLl »
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

Fred vS

  • Hero Member
  • *****
  • Posts: 1983
    • StrumPract is the musicians best friend
Re: Bell for Linux
« Reply #27 on: October 23, 2020, 04:05:17 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.

I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs
https://gitlab.com/fredvs

MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: Bell for Linux
« Reply #28 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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

Fred vS

  • Hero Member
  • *****
  • Posts: 1983
    • StrumPract is the musicians best friend
Re: Bell for Linux
« Reply #29 on: October 23, 2020, 04:45:39 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
« Last Edit: October 23, 2020, 04:48:47 pm by Fred vS »
I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs
https://gitlab.com/fredvs

 

TinyPortal © 2005-2018