Sound, ALSA, development package... I don't understand
Sound, ALSA, development package... I don't understand
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?
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?
Re: Sound, ALSA, development package... I don't understand
Use the static lib, instead of the .so, because this is compiled 'into the program'.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?
Therefore, you're going to be independent, of 'externals' of any kind.
Re: Sound, ALSA, development package... I don't understand
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.
Re: Sound, ALSA, development package... I don't understand
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.
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.
Re: Sound, ALSA, development package... I don't understand
Well, it's actually the same, on Windows called: .dll - hell!
Re: Sound, ALSA, development package... I don't understand
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
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
Re: Sound, ALSA, development package... I don't understand
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.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.
Re: Sound, ALSA, development package... I don't understand
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.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
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.
Re: Sound, ALSA, development package... I don't understand
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.
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.
Re: Sound, ALSA, development package... I don't understand
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:
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:
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:
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
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")
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")
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"
Thank you guys very much
Re: Sound, ALSA, development package... I don't understand
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
Re: Sound, ALSA, development package... I don't understand
On statically linked lib's, you simply *Declare* the procedures (Function/Sub), on top,xlucas wrote:How can I define these functions now so that they point to the static lib being linked?
preferably in a .bi (which then also, loads the *lib*).
They are called "Function Pointers", which are only used with dynamically linked lib's.xlucas wrote:And... why did I, with the dynamic version, need to Dim the functions?
Reading FB's Documentation will help with that. ;-) And, search is a friend ...xlucas wrote:I would like to understand this better.
Also in this Forum, *Libraries* and/or *Tips & Tricks*:
- *Tips & Tricks*, see: GFX_MATH.bi shows, how to make a simple .bi file.
- *Tips & Tricks*, see: Library Tutorial ...
- *Libraries*, see: Color by Percent (static lib)
Re: Sound, ALSA, development package... I don't understand
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.