Sound, ALSA, development package... I don't understand

Linux specific questions.
Post Reply
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Sound, ALSA, development package... I don't understand

Post by xlucas »

Guys, I thought I had understood how this worked, but now I'm puzzled. Some time ago, I made a little game accessing sound in a way similar to what Angros posted some time ago, though multi-channel. Because my program compiled, I assumed any library necessary for it to work was already on the system. Besides, other programs in Linux run without my installing libasound-dev. I asked here before how come I had to install libasound-dev to use ALSA in my programs while other programs I was installing were working without it. I was told the development package would be required at the time of compilation only and that my programs would likely run out of the box without it once compiled.

Today, I try to run this game and I get no sound.... using the same executable I had complied back then. So I try running the Windows executable (since I had ported it) and Wine runs it fine with sound and all. Then I go to the console and do sudo apt-get install libasound-dev and when I come back, without recompiling, my program now runs with sound natively. How come?

What would be the correct way to access sound so that no library has to be installed for it to work, except what comes with the OS?
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Sound, ALSA, development package... I don't understand

Post by MrSwiss »

xlucas wrote:What would be the correct way to access sound so that no library has to be installed for it to work, except what comes with the OS?
Use the static lib, instead of the .so, because this is compiled 'into the program'.
Therefore, you're going to be independent, of 'externals' of any kind.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Sound, ALSA, development package... I don't understand

Post by caseih »

libasound-dev is only required for compiling. It provides the headers the compiler needs to access the libasound library. By default, though your binary will require libasound to be installed (again, not the -dev package). You can us the "ldd" command to check your binary to see exactly what shared libraries it links against. Sometimes the requirement is for a specific major version (minor version differences shouldn't matter). To link against the static version of the library, try just adding libasound.a to your compile command. Static libraries link in just like normal object files.
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Sound, ALSA, development package... I don't understand

Post by xlucas »

Thanks, guys. Yes... I'll link it statically. I need to see how to change my code, because after loading the dynamic library, it was creating all kinds of definitions and now they're duplicate. I have to see if I need to redefine or if I can use the prototypes that compile in by default. Also, I got really lost when I read in the ALSA site that ALSA recommends using the .so file. If this were what people are doing, then why don't all distros include that file already? Strange thing.

You know, I love free software, but this craze for shared libs and the dependency hell... ugh! I understand why Linux doesn't have more followers. If I hated Windows a little less, I would have left Linux, ha, ha. Thanks again for your help, guys.
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Sound, ALSA, development package... I don't understand

Post by MrSwiss »

Well, it's actually the same, on Windows called: .dll - hell!
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Sound, ALSA, development package... I don't understand

Post by xlucas »

Does it really get so bad in Windows too? :O
I think this dynamic object thing is a fashion, just like OOP... nothing rational in it. Just preference, taste. No reason for this trend. Just my opinion :P
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Sound, ALSA, development package... I don't understand

Post by caseih »

xlucas wrote:Thanks, guys. Yes... I'll link it statically. I need to see how to change my code, because after loading the dynamic library, it was creating all kinds of definitions and now they're duplicate. I have to see if I need to redefine or if I can use the prototypes that compile in by default. Also, I got really lost when I read in the ALSA site that ALSA recommends using the .so file. If this were what people are doing, then why don't all distros include that file already? Strange thing.
So what's happening is that your .bi file is probably instructing the compiler to link in the shared library. So adding the static library is conflicting with the existing shared library link. You need to tell FB not to link to libasound. If you're not specifying it with a "-lasound" flag, then it must be a metacommand in the .bi file itself.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Sound, ALSA, development package... I don't understand

Post by caseih »

xlucas wrote:Does it really get so bad in Windows too? :O
I think this dynamic object thing is a fashion, just like OOP... nothing rational in it. Just preference, taste. No reason for this trend. Just my opinion :P
Umm, trend? Are you serious? Shared libraries and subroutines have been in the mainstream computing landscape for many decades now. I assure you they are not just a fashion, nor irrational, nor preference, nor taste. They are fundamental building blocks.

And actually DLLs in Windows are far worse than the problems you have in Linux. DLLs, though they have internal version numbers, are not stored with a version number in the name. So on Linux you can multiple versions of an so exist side by side, with different version numbers in their name, and binaries can link against either libfoo.so (any version will do), libfoo.so.major (specific series of versions required), or libfoo.so.major.minor (absolutely specific dll) depending on what version specificity they need. It's a pretty neat system, exploiting symlinks. You can see what you binary links against with the "ldd" command. Running that command should be your first thought when you encounter a linking problem.

Your original post is unclear. After you installed libasound-dev it worked without a recompile? You said your program worked but it had no sound? If it really was a missing library, you'd have got a linker error when you tried to run it. Sounds to me like your sound system wasn't quite right and somehow one of the scripts that ran when you installed libasound-dev must have fixed it. In fact it could have been a PulseAudio glitch. PulseAudio, though it's been pretty awesome for years, does have the occasional bug. PulseAudio looks like a normal Alsa device, but it's a mixing layer above the real Alsa device. Wine probably bypassed PulseAudio and went straight to Alsa, which is why it worked. that's my guess anyway.

Definitely as I said that package is *not* required to run a binary linked against libasound. However the normal debian libasound package would be required, it if it was not installed, installing libasound-dev would have installed it as well. the asound shared library is a standard distro component, but there are major updates to it from time to time. Sometimes distros compensate for incompatibilities by installing multiple versions of the library.
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Sound, ALSA, development package... I don't understand

Post by xlucas »

By trend, I mean, I know shared libraries exists since a long time ago, but previously, it was not customary for software to depend on libaries that they didn't include and that were not guaranteed (or almost) to be present in the OS. I agree with the use of shared libraries if they are part of the OS because it's the same as calling interrupts in DOS, for example. I also agree with using shared libraries as "plugins" that you include with your programs, etc., but the problem is now you download a program and you don't know if you have all the pieces or where to get those pieces from. That's the "trend".

What happened to my code is that I was dynamically linking libasound and then defining functions through Dims. Now, if I link statically, the functions are already defined and FB throws "duplicate definition", which makes sense to me. But I'm not sure if I should just delete all the definitions I had made. I have to test. Because maybe some names are not identical or something. I'll do that.

What I still don't understand is why I had no sound. It's probably like you explained because I didn't get a "lib not found" error.
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Sound, ALSA, development package... I don't understand

Post by xlucas »

Help! I haven't been able to switch to static. I'm sure there's something I'm not understanding. What I have is this:

My software used to access sound via the dynamic version of libasound. That works. It first Dims a pointer and then loads the shared library like this:

Code: Select all

Dim Shared As Any Ptr alsa
alsa = DyLibLoad("asound")
After that, I begin to define one by one the functions I'm going to use, following the example I learnt from Angros. For example:

Code: Select all

Dim Shared snd_pcm_close As Function (ByVal pcm As snd_pcm_t) As Integer
snd_pcm_close = DyLibSymbol(alsa, "snd_pcm_close")
If I don't Dim this, the function won't work, so I understand that loading a library does not link the functions. I have to do it myself. Right?
Now, I want to switch to the static libasound, so I remove the first two lines and replace them with:

Code: Select all

#inclib "asound"
The result... of course, now the pointer called "alsa" is not defined, so there's no way I can point my functions to the static lib, as it is attached to no pointer. Curiously, if I keep the first two lines, the #inclib does not cause duplicate definitions (which I'm sure somehow happened to me in the past). No idea what I did then. How can I define these functions now so that they point to the static lib being linked? And... why did I, with the dynamic version, need to Dim the functions? I would like to understand this better.

Thank you guys very much
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Sound, ALSA, development package... I don't understand

Post by dodicat »

I use windows, but maybe try:

Code: Select all



#inclib "asound"
declare function snd_pcm_close alias "snd_pcm_close" (ByVal pcm As snd_pcm_t) As Integer
or
declare function snd_pcm_close cdecl alias "snd_pcm_close" (ByVal pcm As snd_pcm_t) As Integer
'==============================
or
(without #inclib)
declare function snd_pcm_close lib "asound"  alias "snd_pcm_close" (ByVal pcm As snd_pcm_t) As Integer 
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Sound, ALSA, development package... I don't understand

Post by MrSwiss »

xlucas wrote:How can I define these functions now so that they point to the static lib being linked?
On statically linked lib's, you simply *Declare* the procedures (Function/Sub), on top,
preferably in a .bi (which then also, loads the *lib*).
xlucas wrote:And... why did I, with the dynamic version, need to Dim the functions?
They are called "Function Pointers", which are only used with dynamically linked lib's.
xlucas wrote:I would like to understand this better.
Reading FB's Documentation will help with that. ;-) And, search is a friend ...

Also in this Forum, *Libraries* and/or *Tips & Tricks*:
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Sound, ALSA, development package... I don't understand

Post by xlucas »

Thank you, guys. I actually figured it out before I came back to the forum, but it's still good to know why and how. I'll take a deeper read to the manuals.
Post Reply