Topic: libbassenc_mp3 load problem on linux ubuntu 20.04

[serkanp]

hi Ian,
i am developing a dotnet core app with visual studio which will work on linux and windows,
i am using libbass_fx.so, libbassenc.so, libbassenc_mp3.so, libbassmix.so, libtags.so  and same libs for windows
on windows all libs works without any problem.
on linux ubuntu 20.04 (wsl2 and vmware desktop ubuntu), all libs works except libbassenc_mp3.so

when i use BassEnc_Mp3.BASS_Encode_MP3_Start i get:
unable to load shared library 'bassenc_mp3' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libbassenc_mp3: cannot open shared object file: No such file or directory

when i use a test code

Code: [Select]

var path = Path.Combine(Environment.CurrentDirectory, "libbassenc_mp3.so");
                    if (File.Exists(path))
                    {
                        Console.WriteLine("File Exists");
                    }
                    var res = Bass.BASS_PluginLoad(path);
                    var err = Bass.BASS_ErrorGetCode();
                    var ver = BassEnc.BASS_Encode_GetVersion(4);
                    var ver1 = BassEnc_Mp3.BASS_Encode_MP3_GetVersion(4);
File Exists
res is 0 and
err is BASS_ERROR_FILEOPEN
BassEnc version 2.4.15
ver1 gives the same error:unable to load shared library 'bassenc_mp3' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libbassenc_mp3: cannot open shared object file: No such file or directory

but the file is there..

but all .so files are at the same path and all x64 versions of it.. i checked and replaced 4-5 times with the latest one on the un4seen.com site..
same code works on windows with the same libs of windows x64..

what is the problem?

[Ian @ un4seen]

Are the BASS libraries alongside your executable? Please open that directory in Terminal and run file *.so and then copy and paste the output here.

Btw, it isn't possible to load BASSenc add-ons via BASS_PluginLoad (that's only for adding file formats to the stream/sample functions), so you can remove that call.

[serkanp]

Are the BASS libraries alongside your executable? Please open that directory in Terminal and run file *.so and then copy and paste the output here.

$ file *.so
libbass.so:        ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
libbass_fx.so:     ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
libbassenc.so:     ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
libbassenc_mp3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
libbassmix.so:     ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
libtags.so:        ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

Btw, it isn't possible to load BASSenc add-ons via BASS_PluginLoad (that's only for adding file formats to the stream/sample functions), so you can remove that call.

this also gives the same error ,

Code: [Select]

int id=BassEnc_Mp3.BASS_Encode_MP3_Start(mixerChannel, BuildLameString(_configuration), BASSEncode.BASS_ENCODE_LIMIT, null, IntPtr.Zero);

also

Code: [Select]

BassEnc_Mp3.BASS_Encode_MP3_GetVersion(4);
gives the same error..



i tested it with both radio42 bass.net  and managedBass libraries , also i manually dllimported the component.. all same...

[radio42]

This is indeed very strange. I am not a Linux user myself. But here are the signatures of BassEnc as well as the BassEnc_Mp3 add-on. Both are 100% identical, as such, I do not see any reason, why the _GetVersion call would succeed on BassEnc, but fail on BassEnc_Mp3:

1: BassEnc:

Code: [Select]

[DllImport("bassenc")]
public static extern int BASS_Encode_GetVersion();

2: BassEnc_Mp3:

Code: [Select]

[DllImport("bassenc_mp3")]
public static extern int BASS_Encode_MP3_GetVersion();

Note, as Ian suggested to remove the call to BASS_PluginLoad(path) as this is not intended to load the encoder add-ons.
Maybe you can simply your test to:

Code: [Select]

var ver = BassEnc.BASS_Encode_GetVersion();
var err = Bass.BASS_ErrorGetCode();

var ver1 = BassEnc_Mp3.BASS_Encode_MP3_GetVersion();
var err1 = Bass.BASS_ErrorGetCode();


[serkanp]

This is indeed very strange. I am not a Linux user myself. But here are the signatures of BassEnc as well as the BassEnc_Mp3 add-on. Both are 100% identical, as such, I do not see any reason, why the _GetVersion call would succeed on BassEnc, but fail on BassEnc_Mp3:

1: BassEnc:

Code: [Select]

[DllImport("bassenc")]
public static extern int BASS_Encode_GetVersion();

2: BassEnc_Mp3:

Code: [Select]

[DllImport("bassenc_mp3")]
public static extern int BASS_Encode_MP3_GetVersion();

Note, as Ian suggested to remove the call to BASS_PluginLoad(path) as this is not intended to load the encoder add-ons.
Maybe you can simply your test to:

Code: [Select]

var ver = BassEnc.BASS_Encode_GetVersion();
var err = Bass.BASS_ErrorGetCode();

var ver1 = BassEnc_Mp3.BASS_Encode_MP3_GetVersion();
var err1 = Bass.BASS_ErrorGetCode();


when calling the code example you said, ver=2.4.15.0 , err=BASS_OK
when it comes to ver1 , it fails and gives the error :Unable to load shared library 'bassenc_mp3' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libbassenc_mp3: cannot open shared object file: No such file or directory
and not continues the next line err1

one interesting thing i found that, if you call

Code: [Select]


var initresult = Bass.BASS_Init(_soundCard, _frequency, _initFlags, IntPtr.Zero);
 var ver1 = BassEnc.BASS_Encode_GetVersion(4); //this gives the same kind error..
 var err1 = Bass.BASS_ErrorGetCode();

ver1 gives the same kind error  ('Unable to load shared library 'bassenc' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libbassenc: cannot open shared object file: No such file or directory')

but if you put a mixer after bass init,  BassEnc.BASS_Encode_GetVersion(4) works..

Code: [Select]


var initresult = Bass.BASS_Init(_soundCard, _frequency, _initFlags, IntPtr.Zero);
 var mixer= BassMix.BASS_Mixer_StreamCreate(44100, 2, BASSFlag.BASS_DEFAULT);//if you put this
 var ver1 = BassEnc.BASS_Encode_GetVersion(4); //now it works.
 var err1 = Bass.BASS_ErrorGetCode();

var ver2 = BassEnc_Mp3.BASS_Encode_MP3_GetVersion(); //this still not works..
var err2 = Bass.BASS_ErrorGetCode();



so i think, from now, ian have to check it..
ps: radio42, do you have wsl/wsl2 on your windows 10/11?
you can easily test it.. after wsl or wsl2 install , install ubuntu20 to wsl.. then open visual studio 2022, create a dotnet core console app or dotnet standart dll + dotnet core app,
when you press dropdown button near run, you will see wsl2 option.. it will directly start debugging on ubuntu.. i tested on real ubuntu , wsl, wsl2, console etc.. all same..

 
 

[serkanp]

one more interesting thing:

Code: [Select]

$ ldd libbassmix.so
        linux-vdso.so.1 (0x00007ffca05e1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f04db1a9000)
        libbass.so => /mnt/d/workspace/codes/SMG/SaasPlayer/consolePlayer/bin/Debug/net5.0/./libbass.so (0x00007f04daf5c000)  <-- libbassmix knows where libbass.so
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f04daf51000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f04dae02000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f04dac10000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f04db3ea000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f04dac0a000)
$ ldd libbassenc.so
        linux-vdso.so.1 (0x00007ffc4af58000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f34af8f3000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f34af8e8000)
        libbass.so => not found  <-- libbassenc.so does not know or resolve where it is..
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f34af6f6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f34afb36000)
$ ldd libbassenc_mp3.so
        linux-vdso.so.1 (0x00007ffc3df88000)
        libbass.so => not found  <--same here
        libbassenc.so => not found  <--same here
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3c3cd83000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3c3cb91000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3c3d11a000)

so without calling any mixer function after bass init, libbassenc.so does not work.. but after a mixer, somehow, libbassenc.so now knows where libbass.so and itself and dllimport works on it..

maybe same problem is happening on libbass_mp3.. 

[serkanp]

and one more investigation on Macosx monterey..

Code: [Select]

var initresult = Bass.BASS_Init(_soundCard, _frequency, _initFlags, IntPtr.Zero);
 //without any mixer
 var ver1 = BassEnc.BASS_Encode_GetVersion(4); //it works.
 var err1 = Bass.BASS_ErrorGetCode();

var ver2 = BassEnc_Mp3.BASS_Encode_MP3_GetVersion(); //also this works too..
var err2 = Bass.BASS_ErrorGetCode();

on macosx, same code works without any problem..
so, problem is definitely about the linux version..
tomorrow i will test it on raspberry, then later, i might test on android and ios too.. )
 

[radio42]

Many thanks for all these findings, and I agree. It sounds like a very Linux specific issue.

[Ian @ un4seen]

one more interesting thing:

Code: [Select]

$ ldd libbassmix.so
        linux-vdso.so.1 (0x00007ffca05e1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f04db1a9000)
        libbass.so => /mnt/d/workspace/codes/SMG/SaasPlayer/consolePlayer/bin/Debug/net5.0/./libbass.so (0x00007f04daf5c000)  <-- libbassmix knows where libbass.so
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f04daf51000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f04dae02000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f04dac10000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f04db3ea000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f04dac0a000)
$ ldd libbassenc.so
        linux-vdso.so.1 (0x00007ffc4af58000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f34af8f3000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f34af8e8000)
        libbass.so => not found  <-- libbassenc.so does not know or resolve where it is..
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f34af6f6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f34afb36000)
$ ldd libbassenc_mp3.so
        linux-vdso.so.1 (0x00007ffc3df88000)
        libbass.so => not found  <--same here
        libbassenc.so => not found  <--same here
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3c3cd83000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3c3cb91000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3c3d11a000)

so without calling any mixer function after bass init, libbassenc.so does not work.. but after a mixer, somehow, libbassenc.so now knows where libbass.so and itself and dllimport works on it..

maybe same problem is happening on libbass_mp3..

I'm guessing that the issue is related to the library search path, ie. it doesn't include the location of those libraries, so Linux can't find them. BASSmix (and other recently updated add-ons - BASSHLS/OPUS) includes a setting that tells Linux to look in the same directory for dependencies, so that's probably what's helping in that case. Neither BASSenc or BASSenc_MP3 include that setting yet, but here are updated builds that do, for you to try:

   www.un4seen.com/stuff/bassenc-linux.zip
   www.un4seen.com/stuff/bassenc_mp3-linux.zip

Let me know whether it helps.

[serkanp]

I'm guessing that the issue is related to the library search path, ie. it doesn't include the location of those libraries, so Linux can't find them. BASSmix (and other recently updated add-ons - BASSHLS/OPUS) includes a setting that tells Linux to look in the same directory for dependencies, so that's probably what's helping in that case. Neither BASSenc or BASSenc_MP3 include that setting yet, but here are updated builds that do, for you to try:

   www.un4seen.com/stuff/bassenc-linux.zip
   www.un4seen.com/stuff/bassenc_mp3-linux.zip

Let me know whether it helps.

yesssss!.. it works..! perfect.. thank you..
and what about the arm and android versions? can you check if the same problem exists on them also?

[Ian @ un4seen]

Good to see that the update fixed the problem you were having. The BASSenc_MP3 update is up on the BASS page now, along with similar updates of the other BASSenc add-ons. The BASSenc update isn't there yet, but a new release is coming soon (the update posted above is a beta of that).

Android shouldn't be affected, but you may have the same issue on ARM Linux, so here are ARM Linux updates too:

   www.un4seen.com/stuff/bassenc24-linux-arm.zip