Recent

Author Topic: Help with Alsa C conversion.  (Read 8561 times)

TRon

  • Hero Member
  • *****
  • Posts: 2435
Re: Help with Alsa C conversion.
« Reply #30 on: August 06, 2020, 12:31:39 pm »
Here is my code for my 2 procedures.  Much better now.
Nice. See, how that cleans up your code ?  :)

Quote
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 ?

Quote
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.

Quote
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!
Strange.

Have you tried MarkMLI's suggestion of using a smaller capture buffer ? The only thing different would be that the buffer is smaller so you would have to read multiple buffers in case you wish to record/copy a larger amount of samples.

Because 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) ?

Quote
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  :)

What 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 ?


What you could also try is doing a latency test. ALSA comes accompanied with an example, see here https://www.alsa-project.org/wiki/Test_latency.c (actual code is linked on that page).

If the latency test works for your hardware, then the issue is probably related to the code that you've tried. At least you would perhaps be able to get some inspiration from that code  ;)

To make sure, I repeat the warning about ALSA sometimes being finicky. If your code ever failed for whatever reason and handles/memory was not freed correctly then ALSA is able to throw in very strange error's (on successive runs) that make no sense (at least not to me) and can lead to confusion when you try to debug things. Reset often in such cases.

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Help with Alsa C conversion.
« Reply #31 on: August 06, 2020, 03:21:16 pm »
Quote
I 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.

If you use Portaudio library, it can use or ALSA or PulseAudio (if installed on your system).
You will directly see the difference of latency and quality if you use PulseAudio drivers vs ALSA drivers.

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

TRon

  • Hero Member
  • *****
  • Posts: 2435
Re: Help with Alsa C conversion.
« Reply #32 on: August 06, 2020, 03:38:04 pm »
Huh, even more, ALSA is obsolete now.
So true indeed Fred vS

Even ALSA developers/documentation advise to use for example jack.

I did take my queue from Topic Starter though. I have only tried to use it with FPC because I noticed there was a unit for using it with FPC and wanted see how that would work.

My conclusion was that it was decent enough. However, you do need to have a fair bit of understanding of ALSA before you can actually make it do the things you want to.

Pulseaudio, as you suggested, is indeed also a far better option imho.

AL

  • Sr. Member
  • ****
  • Posts: 261
Re: Help with Alsa C conversion.
« Reply #33 on: August 06, 2020, 03:46:16 pm »
Quote
Quote
What 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
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.

Quote
Quote
Because 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) ?
Good idea tis may do it.  Will try it.


Do we have a FPC unit that bridge to the PulseAudio API?
Laz 3.1, fpc 3.2.2, Win10
Laz 3.1  fpc 3.2.2, MacOS Monterey running on VMWare/Win 10
Laz 3.1  fpc 3.2.2 Ubuntu 20.04

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Help with Alsa C conversion.
« Reply #34 on: August 06, 2020, 03:58:21 pm »
Quote
I 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).

TRon

  • Hero Member
  • *****
  • Posts: 2435
Re: Help with Alsa C conversion.
« Reply #35 on: August 06, 2020, 04:02:34 pm »
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.

Have you already been able to look at the latency example ? If you did, where you also able to locate and understand how EAGAIN is handled with the loop ? (just ignore the fact that the c-example also play/time the data in order to be able to calculate the latency)

Quote
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

Perhaps Fred vS (author of UOS sound library) or someone else knows about another version somewhere ?

TRon

  • Hero Member
  • *****
  • Posts: 2435
Re: Help with Alsa C conversion.
« Reply #36 on: August 06, 2020, 04:10:42 pm »
Quote
I 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).
I can not speak for Fred vS but, I interpreted his words as not using ALSA directly (anymore).

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.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Help with Alsa C conversion.
« Reply #37 on: August 06, 2020, 04:20:11 pm »
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.

Neither am I, but I've had to look at this a little bit in an (unsuccessful) attempt to sort out some startup dependencies.

I agree that ALSA is part of the kernel, but it appears to have a mutual dependency on PulseAudio, at least for certain media types (my interest is MIDI, which I use for annunciators).

But correct me if wrong, I'm no expert :-)

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: Help with Alsa C conversion.
« Reply #38 on: August 06, 2020, 05:53:26 pm »
Quote
Perhaps Fred vS (author of UOS sound library) or someone else knows about another version somewhere ?
I use the one from Andrew :
https://github.com/andrewd207/fpc-pulseaudio

And there is also the source from Martin:
https://github.com/mse-org/mseide-msegui/blob/master/lib/common/audio

uos uses PortAudio library that can deal with ALSA, PulseAudio, Jack and many others.
http://www.portaudio.com/

Quote
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.

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

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: Help with Alsa C conversion.
« Reply #39 on: August 06, 2020, 06:07:27 pm »
Quote
 
Quote
PulseAudio 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
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: 6676
Re: Help with Alsa C conversion.
« Reply #40 on: August 06, 2020, 06:10:41 pm »
Citation required, from ALSA or Linux projects rather than hearsay.

I'm sorry, but this is something where something authoritative is really needed.

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: Help with Alsa C conversion.
« Reply #41 on: August 06, 2020, 07:10:04 pm »
Citation required, from ALSA or Linux projects rather than hearsay.

I'm sorry, but this is something where something authoritative is really needed.

MarkMLl

Ok, ok, indeed Wikipedia is the biggest hearsay, sorry for that ridiculous link.

[EDIT] Anyway you may check that long topic in mailing list, even I did not agree with Martin and PulseAudio working without ALSA:

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.

But the argument of Martin are too strong, he win.

Fre;D
« Last Edit: August 06, 2020, 07:58:28 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

dliw

  • New Member
  • *
  • Posts: 21
Re: Help with Alsa C conversion.
« Reply #42 on: August 06, 2020, 08:40:17 pm »
Quote
 
Quote
PulseAudio 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.
« Last Edit: August 06, 2020, 08:51:40 pm by dliw »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Help with Alsa C conversion.
« Reply #43 on: August 06, 2020, 08:42:16 pm »
Thanks for the additional info Fred.

Whatever its strengths, Wp is at best a secondary source... or even worse if we take its "Article relies excessively on primary sources" strictures to heart. As an example, I'd point to its claim that FPC supports SPARC64 on Linux and SPARC on SunOS/Solaris... the code might be in there but historically I've been the one testing SPARC on actual hardware and I've been able to put minimal time into it since the 2.7.1 era.

MarkMLl
« Last Edit: August 06, 2020, 08:43:57 pm by 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

AL

  • Sr. Member
  • ****
  • Posts: 261
Re: Help with Alsa C conversion.
« Reply #44 on: August 07, 2020, 01:42:41 am »
Tried several things.

Adding application.processmessages to the timer event does not work.
Even adding the following code right after the read does not update the progressbar.
I believe there is a problem with the progressbar itself.
 
Code: Pascal  [Select][+][-]
  1. Application.processmessages ;
  2.  
  3.   err := snd_pcm_readi (capture_handle, buffer, buffer_frames);
  4.   mainform.ProgressBar1.Position:= 1000;
  5.   Application.ProcessMessages ;
This should put the progressbar at mid position, but nothing happen.

This is my first experience with Linux (Ubuntu 20.04) .
The widget is GTK2 is that OK, could / should I use something else?
Laz 3.1, fpc 3.2.2, Win10
Laz 3.1  fpc 3.2.2, MacOS Monterey running on VMWare/Win 10
Laz 3.1  fpc 3.2.2 Ubuntu 20.04

 

TinyPortal © 2005-2018