Recent

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: alsa beep - linux only
« Reply #60 on: November 03, 2020, 08:57:17 am »
I continue to tinker with this at the lower levels, since now that I realise that some of my earlier problems (OS-version specific etc.) were due to alsapas I'm keen to be able to move over to MIDI via a shared object interface.

Since Fred's raised the (L)GPL, one comment if I may. The bulk of the fpalsa stuff is purely declarative, with the exception of a few inline functions intended to replace C macros. I note that Google et al. are claiming that interface declarations aren't subject to copyright since they are statements of fact rather than "literary works", and that most of the industry- with the obvious exception of Oracle- appears to have fallen in line behind them.

Obviously where I've transcluded headers which have a preexisting LGPL header I'm leaving it intact. But I suspect that a license on material that can't be copyrighted is ineffective, and am a little concerned lest the current habit of sticking (L)GPL boilerplate into absolutely every file is potentially strengthening Oracle's case.

My preferred practice, where a language supports separate declaration and implementation files, is to explicitly put the declaration part in the public domain and to explicitly put an (L)GPL at the start of the implementation part. And also to avoid mixing macros into the declaration part.

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 #61 on: November 03, 2020, 12:35:18 pm »
Hello everybody.

I have a question about license.

What about using C header translated into Pascal?

For example here in alsa_sound project very few part of code is from fpalsa.

But, using the translator h2pas to translate alsa.h I get the same unit and can use it.

So there is something that trouble me, why should I follow the license of fpalsa if h2pas does perfectly the job?

Thanks.

Fre;D
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: 6646
Re: alsa beep - linux only
« Reply #62 on: November 03, 2020, 01:47:17 pm »
I am not a lawyer, but from watching this stuff I'd say that the named entry points and the parameter list are statements of fact so cannot be copyrighted (hence possibly cannot have a license meaningfully associated with them), while parameter names and underlying type names might be explanatory so can be copyrighted/licensed. Comments and overall layout can most definitely be copyrighted, indexed entry points as used by DLLs probably have less protection than named ones.

Hence the output of h2pas definitely cannot have a stronger license than the input, and particularly if parameters and types are renamed are probably "res nullius" i.e. owned by nobody in particular as distinct from being owned by somebody but put in the public domain for free use.

Macros in a C/C++ header file are another can of worms entirely.

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 #63 on: November 03, 2020, 02:10:14 pm »
Thanks MarkMLI for your light.

I have indeed some problems with the use of part of headers and the Indisputable Truth.

For example if I use some methods from a translated C header that use Static-loading of libraries  (external 'thelib') and change it into Dynamic-loading (loadlibrary('thelib') what is the status?

Because I changed the source, what about the license, is it a violation, must I notify somebody?

Fre;D

« Last Edit: November 03, 2020, 02:18:57 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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: alsa beep - linux only
« Reply #64 on: November 03, 2020, 05:35:03 pm »
Again with the caveat that I am not a lawyer, and suspecting that the Oracle vs Google case demonstrates that lawyers haven't really got to grips with this stuff.

For example if I use some methods from a translated C header that use Static-loading of libraries  (external 'thelib') and change it into Dynamic-loading (loadlibrary('thelib') what is the status?

I'd have thought that the overriding concern is the license under which you have been provided with the library- whether it be statically or dynamically linked- plus local case history on reverse engineering and clean-room regeneration via a specification.

If you have a declaration (e.g. Pascal interface section) which includes material which is recognisably a transcript of something subject to copyright and have not been licensed to use it, then you are at fault irrespective of the languages involved.

If you have reverse-engineered an interface in line with local convention (statute and precedent) which describes DLL-style numbered entry points, or a jump table at an absolute location in memory, and this contains absolutely no recognisable text, then I cannot see how you can be faulted.

If you have transcribed an interface which described named entry points, then you would possibly be liable for your use of identifiers such as open() or snd_pcm_open(). A court might or might not accept a defence of "it's obvious" or "it's the only way of doing it": those would invalidate a patent, but not necessarily copyright.

A court would probably apply the same reasoning to a data structure with named fields, however unreasonable this might appear to somebody "skilled in the art".

The libasound binary is undoubtedly subject to copyright, and to the copyright holders' chosen license. The .h files that accompany it are annotated as being subject to the LGPL. Whether a (Pascal) transcript of the .h files is also subject to the LGPL probably depends (a) on whether comments etc. have been carried over and (b) on whether some arcane interpretation of the (L)GPL allows a header file to be read with the intention of generating a clean-room specification.

I'm not sure that makes things any clearer, but it's the situation as I see it.

Quote
Because I changed the source, what about the license, is it a violation, must I notify somebody?

If somebody had asserted copyright over a file which you changed and supplied it subject to a license which says you must tell them, then yes.

I speculate that you don't have to tell anybody if you generate a cleanroom copy, subject to the (L)GPL being interpreted to allow this or your demonstration that you've done it from a binary without reference to the source.

It's a mess. It's far easier- at least with scratch-written software- to explicitly designate interface files as a statement of fact hence not being copyrightable, with the caveat that if local laws prohibit this that they're in the public domain. At the very least, that avoids risk that the (L)GPL be weakened by a challenge.

Mixing declaration and implementation, including C/C++ macros, in a single file is asking for trouble.

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 #65 on: November 03, 2020, 10:48:38 pm »
Hi!

Donald Trump breaks laws and does not respect the Constitution.
The same with Boris Johnson and Angela Merkel.
Not to talk about all those dictators which surround us in Turkey,
Russia or Hungary and Poland.

So why should I worry about license stuff?

Winni
 

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: alsa beep - linux only
« Reply #66 on: November 03, 2020, 11:14:03 pm »
Because you're better than they are and you know it.

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: 6646
Re: alsa beep - linux only
« Reply #67 on: November 06, 2020, 01:43:45 pm »
Here's my take on a partial ALSA interface based on fpalsa etc. (i.e. as is currently being discussed).

It includes support for PCM and sequencer devices, but only to the extent that this is necessary for the sort of PCM demo we've been kicking around and the sort of MIDI stuff I'm using for annunciator jingles. I've folded in as many comments as I can from the main ALSA documentation site so that they show up in the IDE.

It includes both static- and dynamically-linked variants, both test OK. The dynamic linkage stuff relies on a hack somebody gave me about 20 years ago, and application code can be written to use either subject to (a) a change in the "uses" clause and (b) referring explicitly to AsoundPcm or AsoundSeq wherever routines are used (i.e. provided that (b) is observed then only (a) needs attention).

There's quite a lot of boilerplate involved particularly in the dynamic units, but it's done in such a way that there is a definitive .inc file for each subsystem. If I did this sort of thing often enough, I'd consider a generator program to augment h2pas.

This has allowed me to dispense with alsapas, which had an extremely irritating dependency on the version of the asound library on the target system which meant that I was having to build multiple copies of each application.

I'll stick it onto https://github.com/MarkMLl presently but would appreciate any feedback.

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 #68 on: November 06, 2020, 07:14:45 pm »
Hello MarkMLI

I did try your /examples/BeepDemo.lpi but without luck:

There is a error message: 'Main source code is missing".
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: 6646
Re: alsa beep - linux only
« Reply #69 on: November 06, 2020, 07:57:59 pm »
I've just downloaded the file I posted. Untar, switch to the examples directory, start Lazarus on BeepDemo.lpi. Compiled and ran fine.

No demo for the MIDI side I'm afraid, most of the complexity is in enumerating the available devices.

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 #70 on: November 06, 2020, 10:50:27 pm »
I've just downloaded the file I posted. Untar, switch to the examples directory, start Lazarus on BeepDemo.lpi. Compiled and ran fine.

No demo for the MIDI side I'm afraid, most of the complexity is in enumerating the available devices.

MarkMLl

Hello

I just re-downloaded your file, un-tar it, load the project with Lazarus and try to compile it but I get this (see picture):
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: 6646
Re: alsa beep - linux only
« Reply #71 on: November 06, 2020, 11:09:31 pm »
I just re-downloaded your file, un-tar it, load the project with Lazarus and try to compile it but I get this (see picture):

Using Lazarus trunk 2.1.0 r63879 with FPC 3.0.4 on Debian 10 "stable". No extra packages and nothing special about the compiler.

Only requirement is to use the supplied .lpi in the examples directory, with the support units (both static and dynamic) in ../

Try starting off with the .lpr instead, in case Lazarus has broken backward compatibility.

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 #72 on: November 06, 2020, 11:11:07 pm »
Hello.

I was able to compile your demo using a other IDE.

On my system, only button 'ALSA PCM Beep' produces sound, the 2 others only silence.
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: 6646
Re: alsa beep - linux only
« Reply #73 on: November 07, 2020, 09:48:24 am »
On my system, only button 'ALSA PCM Beep' produces sound, the 2 others only silence.

As expected. You'd probably find that if you ran the program from a shell and echo -e \a worked then the stdout button would also work. The erratic X11 beep we've done to death in the past.

I remembered overnight that a change in the IDE broke file compatibility, but that there's a project-level setting to write compatible files.

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 #74 on: November 07, 2020, 03:01:45 pm »
On my system, only button 'ALSA PCM Beep' produces sound, the 2 others only silence.

As expected. You'd probably find that if you ran the program from a shell and echo -e \a worked then the stdout button would also work. The erratic X11 beep we've done to death in the past.

I remembered overnight that a change in the IDE broke file compatibility, but that there's a project-level setting to write compatible files.

MarkMLl

Hello MarkMLI.

This gives silent on my system (as already explained in other posts).

Code: Bash  [Select][+][-]
  1. fred@fiens ~> echo -e '\a'

So, (also already explained) better to forget it if you want something universal.

But we are all very interested about your MIDI code + example.

Many thanks.

Fre;D

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

 

TinyPortal © 2005-2018