I was sure I tried that, but evidently not. It does work now. Thank youdereferences n, so the pascal code must be:
while (*n != NULL) {
while (n^ <> nil)
PS: your code produces a bunch of memory leaks, try sticking to the c code, because it doesn'tSure will do! :-)
char **hints; int err = snd_device_name_hint(-1, "pcm", (void***)&hints);
After we ported these strings to pascal we can free the memory allocated as PCharcmem.free
Probably this requires the use of the C memory manager (unit cmem) or the use of a specialized function provided by the lib simply by the names I would think that this is probably snd_device_name_free_hint(PPointer(@rawName));afaik snd_device_name_free_hint() should only be used for the hints list. I've never seen it used for anything else.
you should probably also check if the pointer is already nil so you don't try to free nilDefinitely.
cmem.free
cmem.free
It should be noted that for using cmem, it must be the very first unit in the uses clauses auf your lpr file, because it registers a new memory manager and other units might have initialization blocks so the cmem unit needs it's initialization to be executed before any other
(* Note manual addition of cmem below, this is required to allow strings and *)
(* objects to be shared/transferred between the main program and a shared *)
(* library. Note also relative position of HeapTrc, if cmem is used it is not *)
(* possible to specify this at the project level (i.e. use FPC's -gh option). *)
uses
{$ifdef USE_CMEM }
cmem, {$ifdef USE_HEAPTRC } HeapTrc, {$endif }
{$endif }
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Interfaces, // this includes the LCL widgetset
Forms, UnyokedFrontendCode, AlsaMidi, DeviceSelectCode, EventCountersCode
{$ifdef USE_STATIC } , Backend {$else } , DynaMod, BackendDynamic,
Screensaver {$endif USE_STATIC } ;
Note that CMEM is only necessary, if the libraries try to free your allocations, or you must free the libraries allocations.
In both cases, the library is defective. In normal cases this shouldn't be needed. I can't even the remember the last case that I needed it.
Note that CMEM is only necessary, if the libraries try to free your allocations, or you must free the libraries allocations.
In both cases, the library is defective. In normal cases this shouldn't be needed. I can't even the remember the last case that I needed it.
Are you saying that an executable and explicit dynamically-loaded library now share the same FPC memory manager?
Note that CMEM is only necessary, if the libraries try to free your allocations, or you must free the libraries allocations.
In both cases, the library is defective. In normal cases this shouldn't be needed. I can't even the remember the last case that I needed it.
Are you saying that an executable and explicit dynamically-loaded library now share the same FPC memory manager? That certainly didn't used to be the case (although I last looked at in in some depth in about 2013).
marcov is saying that as long as the used library does not require you to free memory passed back from the library or to free memory passed into the library then you do not need cmem. A shared memory manager is only required if memory allocated in module A is freed in module B. Using memory allocated in module A in module B has never been a problem.
@warfley : Your code produce a sigsev at the freemem even using Cmem.Show us some code, or it didn't happen :D
I did put Cmem as the first uses in lpr and in the unit.
./hinting
Name of device : default:CARD=ALSA
Description of device : bcm2835 ALSA, bcm2835 ALSA
Default Audio Device
I/O type of device : Output
Name of device : sysdefault:CARD=ALSA
Description of device : bcm2835 ALSA, bcm2835 ALSA
Default Audio Device
I/O type of device : Output
Name of device : dmix:CARD=ALSA,DEV=0
Description of device : bcm2835 ALSA, bcm2835 ALSA
Direct sample mixing device
I/O type of device : Output
Name of device : dmix:CARD=ALSA,DEV=1
Description of device : bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample mixing device
I/O type of device : Output
Name of device : dmix:CARD=ALSA,DEV=2
Description of device : bcm2835 ALSA, bcm2835 IEC958/HDMI1
Direct sample mixing device
I/O type of device : Output
Name of device : dsnoop:CARD=ALSA,DEV=0
Description of device : bcm2835 ALSA, bcm2835 ALSA
Direct sample snooping device
I/O type of device : Output
Name of device : dsnoop:CARD=ALSA,DEV=1
Description of device : bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample snooping device
I/O type of device : Output
Name of device : dsnoop:CARD=ALSA,DEV=2
Description of device : bcm2835 ALSA, bcm2835 IEC958/HDMI1
Direct sample snooping device
I/O type of device : Output
Name of device : hw:CARD=ALSA,DEV=0
Description of device : bcm2835 ALSA, bcm2835 ALSA
Direct hardware device without any conversions
I/O type of device : Output
Name of device : hw:CARD=ALSA,DEV=1
Description of device : bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct hardware device without any conversions
I/O type of device : Output
Name of device : hw:CARD=ALSA,DEV=2
Description of device : bcm2835 ALSA, bcm2835 IEC958/HDMI1
Direct hardware device without any conversions
I/O type of device : Output
Name of device : plughw:CARD=ALSA,DEV=0
Description of device : bcm2835 ALSA, bcm2835 ALSA
Hardware device with all software conversions
I/O type of device : Output
Name of device : plughw:CARD=ALSA,DEV=1
Description of device : bcm2835 ALSA, bcm2835 IEC958/HDMI
Hardware device with all software conversions
I/O type of device : Output
Name of device : plughw:CARD=ALSA,DEV=2
Description of device : bcm2835 ALSA, bcm2835 IEC958/HDMI1
Hardware device with all software conversions
I/O type of device : Output
Name of device : default:CARD=vc4hdmi
Description of device : vc4-hdmi,
Default Audio Device
I/O type of device : Output
Name of device : sysdefault:CARD=vc4hdmi
Description of device : vc4-hdmi,
Default Audio Device
I/O type of device : Output
Name of device : front:CARD=vc4hdmi,DEV=0
Description of device : vc4-hdmi,
Front speakers
I/O type of device : Output
Name of device : iec958:CARD=vc4hdmi,DEV=0
Description of device : vc4-hdmi,
IEC958 (S/PDIF) Digital Audio Output
I/O type of device : Output
Name of device : dmix:CARD=vc4hdmi,DEV=0
Description of device : vc4-hdmi,
Direct sample mixing device
I/O type of device : Output
Name of device : dsnoop:CARD=vc4hdmi,DEV=0
Description of device : vc4-hdmi,
Direct sample snooping device
I/O type of device : Output
Name of device : hw:CARD=vc4hdmi,DEV=0
Description of device : vc4-hdmi,
Direct hardware device without any conversions
I/O type of device : Output
Name of device : plughw:CARD=vc4hdmi,DEV=0
Description of device : vc4-hdmi,
Hardware device with all software conversions
I/O type of device : Output
Another question, I would like to use the no Block version which uses threads.Which isn't any of your concern as the ALSA library does that. Of course it does have some implications such as some calls will return immediately without waiting.
//*****************error -11 is reported here ************Actually that is EAGAIN, see https://www.freepascal.org/docs-html/rtl/baseunix/esyseagain.html
It does work when I do not use the NONBLOCK parameter, but it freeze the GUI until finished.Yeah, no wonder. You need to update the gui (application.processmessages)
I have added the Uses Cthreads but the 'magic' did not happened.Threads need to be programmed. Your code doesn't magically becomes threaded by adding the threads unit to your uses clause.
The last problem I have is that I use a progress bar driven by a timer to show/imitate the buffer filling. In windows and Mac the GUI does update. In Linux I have not found a way yet.
During the read, the interface is not updated, so the progress bar does not grow!
Here is my code for my 2 procedures. Much better now.Nice. See, how that cleans up your code ? :)
Thanks to all especially TRon who put me on the right track.Thank you, but it seems you are still having issues so perhaps I forgot something ?
I had to use Cmem only to free the name Hint.afaik the hints are the only returns values that require this call. On the other hand I only have used the most common ALSA operations.
The last problem I have is that I use a progress bar driven by a timer to show/imitate the buffer filling. In windows and Mac the GUI does update. In Linux I have not found a way yet.Strange.
During the read, the interface is not updated, so the progress bar does not grow!
Possibly the non Blocking might do the trick, but so far I have not found a way to use it.We're talking ALSA here, but also in general: that is a bit too broad statement :)
I repeat the warning about ALSA sometimes being finicky.
Huh, even more, ALSA is obsolete now.So true indeed Fred vS
In nonblocking mode the readi returns with EAGAIN and I do not know how to handle that properly. Tried a while loop checking err value to match the buffer_frames value with no success.QuoteWhat have you tried and what were the result when your tried them ?
Does your code still locks-up if you set it to non-block ? or is it for example that your read loop is problematic
Good idea tis may do it. Will try it.QuoteBecause you update your progressbar using a timer, what happens if you place the processmessages in your timer event, after you've updated the progressbar (instead of doing so inside your read loop) ?
QuoteI repeat the warning about ALSA sometimes being finicky.
Huh, even more, ALSA is obsolete now.
PulseAudio that was using ALSA at the beginning has developed his own audio drivers and use this now.
In nonblocking mode the readi returns with EAGAIN and I do not know how to handle that properly. Tried a while loop checking err value to match the buffer_frames value with no success.Ah, that is a step further when you reported issues with using it the first time.
Do we have a FPC unit that bridge to the PulseAudio API?Not that I have used this myself but here it seems there is a version: https://github.com/andrewd207/fpc-pulseaudio
I can not speak for Fred vS but, I interpreted his words as not using ALSA directly (anymore).QuoteI repeat the warning about ALSA sometimes being finicky.
Huh, even more, ALSA is obsolete now.
PulseAudio that was using ALSA at the beginning has developed his own audio drivers and use this now.
Source please. From what I know PulseAudio still relies on the kernel's ALSA infrastructure (which does not mean however that it uses libalsa).
afaik pulseaudio is userland, which is more user-friendly, while ALSA is responsible for the direct communication with the underlying device hardware.
But correct me if wrong, i'm no expert.
Perhaps Fred vS (author of UOS sound library) or someone else knows about another version somewhere ?I use the one from Andrew :
I can not speak for Fred vS but, I interpreted his words as not using ALSA directly (anymore).Yes, they have their own source now and dont rely to ALSA anymore.
QuotePulseAudio that was using ALSA at the beginning has developed his own audio drivers and use this now.
Source please
Citation required, from ALSA or Linux projects rather than hearsay.
I'm sorry, but this is something where something authoritative is really needed.
MarkMLl
QuoteQuotePulseAudio that was using ALSA at the beginning has developed his own audio drivers and use this now.
Source please
From https://en.wikipedia.org/wiki/PulseAudio
In a typical installation scenario under Linux, the user configures ALSA to use a virtual device provided by PulseAudio. Thus, applications using ALSA will output sound to PulseAudio, which then uses ALSA itself to access the real sound card. PulseAudio also provides its own native interface to applications that want to support PulseAudio directly, as well as a legacy interface for ESD applications, making it suitable as a drop-in replacement for ESD.
Fre;D
QuoteQuotePulseAudio that was using ALSA at the beginning has developed his own audio drivers and use this now.
Source please
From https://en.wikipedia.org/wiki/PulseAudio
In a typical installation scenario under Linux, the user configures ALSA to use a virtual device provided by PulseAudio. Thus, applications using ALSA will output sound to PulseAudio, which then uses ALSA itself to access the real sound card. PulseAudio also provides its own native interface to applications that want to support PulseAudio directly, as well as a legacy interface for ESD applications, making it suitable as a drop-in replacement for ESD.
Fre;D
Please read this carefully. It only talks about the user facing API: If PulseAudio is active and an (old) application uses the ALSA API directly, it gets redirected to PulseAudio: Application -> Wrapper -> PulseAudio. But (newer) applications can also use the PulseAudio interface directly. However, In both cases PulseAudio uses ALSA to stream the data to the audio hardware.
From https://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture:
Advanced Linux Sound Architecture (ALSA) is a software framework and part of the Linux kernel that provides an application programming interface (API) for sound card device drivers.
The sound servers PulseAudio and JACK (low-latency professional-grade audio editing and mixing), the higher-level abstraction APIs OpenAL, SDL audio, etc. work on top of ALSA and implemented sound card device drivers. On Linux systems, ALSA succeeded the older Open Sound System (OSS).
Edit: In case you don't believe Wikipedia:
From the official page: https://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/
The primary backend used on Linux is ALSA.
QuoteQuotePulseAudio that was using ALSA at the beginning has developed his own audio drivers and use this now.
Source please
From https://en.wikipedia.org/wiki/PulseAudio
In a typical installation scenario under Linux, the user configures ALSA to use a virtual device provided by PulseAudio. Thus, applications using ALSA will output sound to PulseAudio, which then uses ALSA itself to access the real sound card. PulseAudio also provides its own native interface to applications that want to support PulseAudio directly, as well as a legacy interface for ESD applications, making it suitable as a drop-in replacement for ESD.
Fre;D
Please read this carefully. It only talks about the user facing API: If PulseAudio is active and an (old) application uses the ALSA API directly, it gets redirected to PulseAudio: Application -> Wrapper -> PulseAudio. But (newer) applications can also use the PulseAudio interface directly. However, In both cases PulseAudio uses ALSA to stream the data to the audio hardware.
From https://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture:
Advanced Linux Sound Architecture (ALSA) is a software framework and part of the Linux kernel that provides an application programming interface (API) for sound card device drivers.
The sound servers PulseAudio and JACK (low-latency professional-grade audio editing and mixing), the higher-level abstraction APIs OpenAL, SDL audio, etc. work on top of ALSA and implemented sound card device drivers. On Linux systems, ALSA succeeded the older Open Sound System (OSS).
Edit: In case you don't believe Wikipedia:
From the official page: https://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/
The primary backend used on Linux is ALSA.
Correct. One needs to differentiate between the backend drivers (where PulseAudio mainly uses ALSA on Linux) and the frontend where one can use ALSA as a wrapper towards PulseAudio or PulseAudio directly (among other possibilities).
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-pcaudio-td610i20.html
The discussion begin from Mar 09, 2018; 10:57pm Re: [MSEide-MSEgui-talk] MSE pcaudio
@ PascalDragon
All that is not clear.
And I agree, it is important to know the truth.
But does the truth still exist in 2020?
Anyway, I will open a issue in the GitLab site of PulseAudio and ask them what is their truth about PusleAudio using ALSA.
Fre;D
Done: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/959
I hope it will give some clarification.
(And if you see something else to ask, please say it, I will ask).
Now if you're using PulseAudio as audio server
Done: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/959
I hope it will give some clarification.
(And if you see something else to ask, please say it, I will ask).
I assume this is simply a language barrier, so I will try again:
...
Now the audio server needs to handle audio devices, which can be sound cards, HDMI audio outputs or whatever. Right now there is only one infrastructure for this in the Linux kernel and that is called ALSA as well. But compared to the above this is the kernel interface. This did not change with the advent of PulseAudio, because the kernel interface is working well enough for PulseAudio to use. Thus in this context ALSA is still required by PulseAudio. This doesn't matter for an application however, because that picks its API independently of that (it can use libalsa or libpulse depending on its needs).
Thus saying ALSA as a whole is no longer required for PulseAudio is wrong. What is no longer required is the user space part.
What I understood from him is that PulseAudio has now his own audio kernel drivers to deal with the audio cards and they are not the same as ALSA use.
Maybe I am wrong and I would like to be certified by a "official" PulseAudio man.
What I understood from him is that PulseAudio has now his own audio kernel drivers to deal with the audio cards and they are not the same as ALSA use.
Maybe I am wrong and I would like to be certified by a "official" PulseAudio man.
Or even better, by somebody who can speak for the kernel developers and maintainers.
I'm currently downloading the sources from kernel.org since at least part of this can be answered by reference to the build process, but my strong suspicion (which I will come back and correct if necessary) is that there are
* Kernel facilities for ALSA "glue" functionality.
* Kernel drivers for low-level devices.
* /Possibly/ kernel facilities for Pulseaudio.
However note that the low-level drivers are part of neither ALSA nor of Pulseaudio, even though they might be aware of one or the other APIs.
MarkMLl
I finally resorted to split my read in small chunks and call application.processmessages at each read.Would be cheap to say told you so... ;) (actually MarkMLl who did that if not mistaken)
The following is now working and the progressbar updating properly.Thank you for having posted your code. For sure it would be helpful to others.