Recent

Author Topic: alsa beep - linux only  (Read 16845 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: alsa beep - linux only
« Reply #75 on: November 07, 2020, 03:38:31 pm »
OK, I'll try to work on a MIDI example to go with it (definitely won't be today). But it might need manual entry of the device selection numbers.

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: alsa beep - linux only
« Reply #76 on: November 11, 2020, 07:44:16 pm »
Here's an extension of the example to also handle MIDI output. I warn you that it's idiosyncratic, it's basically something that I wrote 20 years ago on Windows which has been hacked about recently to use ALSA on Linux.

I'm not saying it's the best way to do it, I'm not even saying it's a right way to do it (i.e. I'm sure that ALSA MIDI experts would shoot me down). Most of the complexity is in the code that looks at available devices, and works out which of them are useful soundcards etc.

However, I think that the significant thing in my example is the way that I've recycled somebody else's idea to wrap the DLL/so module. I think the only bit I'd claim to be my own is the way that I've organised things so that "AsoundSeq" etc. can be either a unit or an object, which appear identical from the POV of application code.

This stuff gets far more interesting when you write your own dynamically-loadable module (e.g. some sort of plugin), and export entry points from the main program for it to use. However the last time I tried that it was problematic... I don't know if that was because I'd got 64-bit code rather than the 32-bit code I'd used in the past, or if there was something in there specific to a given version of FPC code generation.

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

lazer

  • Full Member
  • ***
  • Posts: 215
Re: alsa beep - linux only
« Reply #77 on: October 16, 2022, 07:36:57 pm »
Jeez, I can't believe there is six pages of this and not a concise , simple way to produce a beep on linux !!!

We are talking about  toggling a single bit on a on IO port somewhere.

Now you need a 64 CPU and an entire sound library to do it !
« Last Edit: October 16, 2022, 07:41:26 pm by lazer »

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: alsa beep - linux only
« Reply #78 on: October 16, 2022, 07:55:05 pm »
Jeez, I can't believe there is six pages of this and not a concise , simple way to produce a beep on linux !!!

We are talking about  toggling a single bit on a on IO port somewhere.

Now you need a 64 CPU and an entire sound library to do it !

Not so simple on Linux, it is why there are more than 5 pages.
The minimum you need is library libasound.so.2 ( 32 or 64 bit ) that is installed by default on nearly all Linux distros.

Here clear demos:
https://github.com/fredvs/alsa_sound/
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: alsa beep - linux only
« Reply #79 on: October 16, 2022, 10:20:24 pm »
Jeez, I can't believe there is six pages of this and not a concise , simple way to produce a beep on linux !!!

We are talking about  toggling a single bit on a on IO port somewhere.

Now you need a 64 CPU and an entire sound library to do it !

Well kiddo, I suggest you take it up with the Linux kernel developers and the distro maintainers. Oh, and the PC designers as well.

I've already made it clear that I believe that a cut-down ALSA PCM routine could usefully be patched in during program startup, after verification that prerequisite libraries etc. existed. I think that Fred is of broadly the same mind.

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

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: alsa beep - linux only
« Reply #80 on: October 16, 2022, 10:43:18 pm »
...
 I think that Fred is of broadly the same mind.

Yes!  ;)

About:
Quote
Now you need a 64 CPU

Hum, not sure to understand, with a OS 32 bit on cpu arm (like RPi) and with the 32 bit libasound.so.2, it works perfectly.
But maybe you are talking about a cpu i386, I did not try, but it should work too.
[EDIT] Tested on cpu i386 and it works too.
« Last Edit: October 16, 2022, 11:14:18 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

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

lazer

  • Full Member
  • ***
  • Posts: 215
Re: alsa beep - linux only
« Reply #81 on: October 17, 2022, 08:12:01 pm »
Quote
Hum, not sure to understand,
Well there was a bit sarcasm in saying 64bit CPU. ;)

On an ARM CPU you'd probably need about 10bytes to beep a piezzo on an IO line.  I have a vague recollection that there's even a BIOS call for this on a PC.

Back in the good old days of Turbo Pascal we still had access to memory mapped IO.

Now, with all the cross platform abstraction it become a major software engineering project !

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: alsa beep - linux only
« Reply #82 on: October 17, 2022, 09:14:17 pm »
Quote
Hum, not sure to understand,
Well there was a bit sarcasm in saying 64bit CPU. ;)

On an ARM CPU you'd probably need about 10bytes to beep a piezzo on an IO line.  I have a vague recollection that there's even a BIOS call for this on a PC.

Back in the good old days of Turbo Pascal we still had access to memory mapped IO.

Now, with all the cross platform abstraction it become a major software engineering project !

I want to make two points here, although it really wouldn't be appropriate for us (collectively) to allow this to mushroom into an off-topic wibble.

The first is that we're stuck with having to go through APIs for this sort of thing. The alternative is to use a platform like Arduino, and to discover- the hard way- that since there's no underlying OS or HAL that using multiple libraries- even well-written ones- is fraught since they inevitably end up contending for timers or other low-level resources.

The second is that I'm not at all happy with the situation, but can't see an easy way out of it.

Mainstream OSes are fundamentally broken, because both major clades (Windows and unix) have at some point made decisions that prioritised speed over robustness and modularisation. This is compounded on the PC architecture by the emphasis on backward-compatibility.

Linux, in particular, has ended up as a monolithic mess. This has been made worse rather than better by the efforts of people to rationalise the situation by adding subsystems with both application-facing and device-facing APIs, I would highlight ALSA/PulseAudio here as well as systemd... in fact we might as well throw in just about anything by Lennart Poettering for good measure.

Noting the Torvalds/Tanenbaum controversy, it's likely that adoption of a microkernel-based OS would, initially, have complicated things by forcing more rather than less API use. However 30 years on, I suspect that we would be seeing significant advantages: if nothing else because the heavy use of IPC between independent daemons would have forced writing use of robust documentation.

The problem there is that architectural choices made in the early 90s would probably have been stifling by the early 00s. For example, unix initially used named devices at a low level with a small number of uniform driver calls... but all of a sudden the proliferation of novel hardware broke this to the extent that the majority of devices now have a user-accessible "backdoor" API (open a named device, use an IOPL to get a pointer to a private entry point, and call that directly). As an older example, I remember an OS that used byte-wide IPC for keyboard input... which broke when programs started working with PC-style scancodes, and was beyond salvage when almost everything wanted to be able to check the held-down state of arbitrary keys... and this included background programs which by rights should be completely isolated from the UI.

So, I'm sorry: on unix, we're stuck with ALSA or something even nastier. And on Windows, while the APIs might arguably be more straightforward you still have to use them: Turbo Pascal was written back before most people had heard of multitasking OSes, and those of us who had to both develop in and support languages of that era used to curse their assumption that they had unfettered low-level access on a regular basis.

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

lazer

  • Full Member
  • ***
  • Posts: 215
Re: alsa beep - linux only
« Reply #83 on: October 17, 2022, 09:46:52 pm »
thanks Mark , an interesting overview.

Sadly it looks like we're stuck in the present with what we have.
Code: Pascal  [Select][+][-]
  1. sudo modprobe snd-pcsp
  2.  
  3. aplay -l
  4. ......
  5. card 2: pcsp [pcsp], device 0: pcspeaker [pcsp]
  6.   Subdevices: 1/1
  7.   Subdevice #0: subdevice #0
  8.  
  9. aplay -D plughw:CARD=pcsp HH.wav
  10. Playing WAVE 'HH.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
  11.  
  12.  

The output suggests its went alright but I don't hear a squeak . :(

{That is a sample sound file from uos.}

Code: Pascal  [Select][+][-]
  1. modprobe pcspkr  
  fails on Fedora.  Has this been stripped from the kernel now?  I could not find any claim of it going .
« Last Edit: October 17, 2022, 09:51:07 pm by lazer »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: alsa beep - linux only
« Reply #84 on: October 17, 2022, 10:43:10 pm »
thanks Mark , an interesting overview.

Thanks. I'm obviously not happy with the situation, but I do my best not to fall into the retro-enthusiast's trap of assuming that reverting to some earlier architecture will cure all evils.

I regularly discuss this sort of thing with my old friend LiamP who tends to espouse a simplistic Lisp- or Oberon-based environment... but goes quiet whenever I point out that his smartphone-de-jour needs facilities that he proposes discarding.

It's a brave OS vendor who tells users they can't have something. It's a suicidal one who removes existing facilities for the users' own good.

Quote
Sadly it looks like we're stuck in the present with what we have.

Unfortunately, I agree. I don't want to comment on the ALSA architecture itself, but though I say so myself I think the example code I put on Github provides about as good an interface to it as possible.

Quote
The output suggests its went alright but I don't hear a squeak . :(

Yes, hence my test program which attempted to make noises in various ways and both Fred and myself agreeing that the results were erratic.

Quote
Code: Pascal  [Select][+][-]
  1. modprobe pcspkr  
  fails on Fedora.  Has this been stripped from the kernel now?  I could not find any claim of it going .

It still appears to be present in Debian, but note that it obviously relies on the PC actually having a speaker and that being wired onto the applicable header (i.e. the single-bit IBM PC or AT speaker rather than an embedded soundcard, noting the possibility of BIOS signal routing or emulation).

I'd also comment that Poettering's former employment by Red Hat suggests that Fedora might not be sympathetic to simple interfaces :-/ **

/However/, we have to ask and have to ask repeatedly: is our demand that some legacy feature be present really helpful? I would argue- and I really don't think we should be extending this here- that by now there is a vast number of things in Linux, in POSIX and for that matter in Object Pascal that should have been removed ages ago: even if doing so did break backwards compatibility.

MarkMLl

** The presence of something like pcspkr is undoubtedly a kernel configuration issue. Rebuilding the Linux kernel is no big deal- back in the early days practically everybody had to do it on a regular basis- but integrating a rebuilt kernel into a mainstream distro is rather more challenging. I don't know whether pcspkr can be rebuilt using the DKMS (?) methodology... there's a couple of projects in my Github repo that use that e.g. the I2C/SPI interfaces.
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

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: alsa beep - linux only
« Reply #85 on: October 17, 2022, 11:10:45 pm »
Code: Pascal  [Select][+][-]
  1. modprobe pcspkr  
  fails on Fedora.  Has this been stripped from the kernel now?  I could not find any claim of it going .

I think it is maybe because pcspkr and snd-pcsp share the same device, just disable snd-pcsp:
Code: Bash  [Select][+][-]
  1. sudo modprobe -r snd-pcsp

Then load pcspkr:
Code: Pascal  [Select][+][-]
  1. sudo modprobe pcspkr

Anyway I did test on Debian 11 both pcspkr and snd-pcsp  with your aplay example ( with HH.wav and others wav ) and get always the same silence (but without any crash or warning).

[EDIT] modprobe pcspkr loads ok but in that case aplay -l does not list pcspkr device. So same problem with Debian.


 
« Last Edit: October 18, 2022, 01:59:07 am by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

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

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: alsa beep - linux only
« Reply #86 on: October 18, 2022, 07:22:07 am »
On the other hand, I see any development that means less things Beeping at me, a good development.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: alsa beep - linux only
« Reply #87 on: October 18, 2022, 09:04:24 am »
On the other hand, I see any development that means less things Beeping at me, a good development.

The industry's matured: everything's been roughed out, and the big question is how to monetize it.

Exactly the same has happened numerous times before: radio, cameras, bicycles, cars, healthcare.

Sound has an API that allows multiple programs to share the limited hardware resource, which generally speaking gets wrapped in simple functions by language implementors. Nobody that matters cares about how it works or how efficient it is these days, far more pressing is persuading the user to subscribe to the right streaming media services.

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: alsa beep - linux only
« Reply #88 on: October 18, 2022, 09:35:45 am »
hi!

There are a  lot of PCs that dont have a PC-Speaker anymore.
So the production is 1.- € cheaper.

If there is no PC-Speaker the module is not loaded.

That's the secret.

Winni

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: alsa beep - linux only
« Reply #89 on: October 18, 2022, 10:11:39 am »
There are a  lot of PCs that dont have a PC-Speaker anymore.
So the production is 1.- € cheaper.

If there is no PC-Speaker the module is not loaded.

That's the secret.

No. The OS doesn't have any way of knowing what- if anything- is attached to the PC header pins.

Fred has demonstrated that it will load it, if asked politely, provided that the module doesn't clash with anything... and provided of course that the distro has included it.

It would, of course, be possible to go back to a bus-based system built of low-cost subassemblies where, if you wanted (say) a beeper, you just plugged in the £5 board and £1 speaker. But that would take us back to the Arduino situation, where multiple programs that wanted to beep would end up trampling on each other. I must say that it is to Microsoft's credit that they have repeatedly tried to rationalise things by various plug-and-play initiatives, but... well, to paraphrase Fred Brooks' paraphrase of Ovid we're still left with a stinking pile.

Everybody's answer a few years ago was to virtualise. These days it's to containerise. But when one scratches the surface and looks at how many disparate namespaces and APIs that abuses on- in particular- Linux one really does have to start worrying.

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

 

TinyPortal © 2005-2018