BASS for ARM Linux

[Ian @ un4seen]

ARM versions of BASS and the add-ons are now included in the Linux packages on the BASS webpage.

The fixed-point "softfp" version is no longer supported, so the last releases including that are still available below.

ARM Linux versions of BASS and the BASSALAC/APE/CD/DSD/FLAC/HLS/MIDI/OPUS/WEBM/WV/mix add-ons are available here:

   www.un4seen.com/files/bass24-linux-arm.zip ^{(updated: 9 Aug '22)}

The BASSenc and BASSenc_FLAC/MP3/OGG/OPUS add-ons are available here:

   www.un4seen.com/files/bassenc24-linux-arm.zip ^{(updated: 24 Feb '22)}

These add-ons are also available:

   www.un4seen.com/stuff/bass_aac-linux-arm.zip
   www.un4seen.com/stuff/bass_ac3-linux-arm.zip
   www.un4seen.com/stuff/bass_mpc-linux-arm.zip
   www.un4seen.com/stuff/bass_spx-linux-arm.zip
   www.un4seen.com/stuff/bass_tta-linux-arm.zip
   www.un4seen.com/stuff/tags-linux-arm.zip
   www.un4seen.com/files/z/0/bass_fx24-linux-arm.zip

The headers and documentation can be taken from the packages on the BASS page. The examples can also be taken from the standard Linux BASS package (replace the MAKEFILE.IN file with the one provided).

3 versions of the libraries are provided: "softfp", "hardfp", and "aarch64". The softfp and hardfp versions require the ARMv6 architecture (or above), while the "aarch64" versions require the 64-bit AArch64/ARMv8 architecture. For performance reasons, the softfp versions use fixed-point rather than floating-point (like the Windows CE version), which means the BASS_SAMPLE_FLOAT flag isn't supported. The BASS_CONFIG_FLOATDSP option is still available then, but it will result in DSPPROC functions receiving 8.24 fixed-point data instead of floating-point. The BASS_CONFIG_FLOAT config option can be used (with BASS_GetConfig) to check whether floating-point is supported (1=yes, 0=no). The hardfp versions support NEON but do not require it.

[AndroidMediaPlayer]

Hi Ian!

What about Plugins for ARM? I also would like to buy a Raspberry PI and run my Player on it (together with my NAS). FLAC and APE would be nice.

Thanx!

Edit: Och, is see, modell b isnt released yet, didn't say anything...

[Ian @ un4seen]

I think that can be arranged. To begin with, an ARM Linux version of the BASSFLAC add-on is now included in the package above. If all is well, other add-ons will follow

[JRfromFL]

Hi Ian !
I'm currently doing some first tests with BASS on the Raspberry Pi using the Debian System and a FPC 2.6.0, which works fine so far.
Do you have an idea, when the BassMix will be available for the ARM Linux ? It would help me a lot, because I want to do crossfades.

Thanks
JR

[Ian @ un4seen]

Good to hear that things are going well so far with the RPi.

As requested, the BASSmix add-on has now been added to the package in the 1st post. Let me know if you have any trouble with it.

[pete]

Hi, I'm unable to get this to work on Raspbian hardfp on Raspberry Pi. I get "error while loading shared libraries: libbass.so: cannot open shared object file: No such file or directory" despite that the library's location is in my LD_LIBRARY_PATH. Any ideas?

[pete]

I suspect the problem is that the library has been built for softp. Would it be possible to rebuild the library using "-march=armv6 -mfpu=vfp -mfloat-abi=hard" or using the hardfp toolchain provided by Broadcom?

Thanks,
Pete

[Ian @ un4seen]

"hardfp" is not supported by the toolchain that is currently used to build the ARM Linux libraries, but I'll see about getting a toolchain that does support it.

[mnstrmnch]

Thanks Ian for the reply Ian, I look forward to any progress on this front.

Regards,
Pete

[ken]

Just did a quick test and I can tell that BASS works fine on Raspberry PI running "Raspbian wheezy". I run C# code using Mono 2.10 with BASS.Net (C# 4.0)

/Ken

[mnstrmnch]

Ken,

Just to confirm - you're running hardfp Raspbian wheezy and not armel Debian wheezy? If so, I wonder what I am doing wrong...

Pete

[ken]

Ken,

Just to confirm - you're running hardfp Raspbian wheezy and not armel Debian wheezy? If so, I wonder what I am doing wrong...

Pete

Pete, do you run the latest build of wheezy? I have problems with earlier versions, mono framework build had some errors. I run "Soft-float Debian "wheezy"" (2012-08-08-wheezy-armel) from http://www.raspberrypi.org/downloads  I have not tested the other builds yet.
 
When installing mono use full version: apt-get install mono-complete

/Ken

[mnstrmnch]

I am running the latest Raspbian wheezy, I will try the Debian wheezy that you mention. Thanks for your help.

Regards,
Pete

[mnstrmnch]

Okay, working fine with Debian wheezy  Thanks for the help. It would still be good to get a version for Raspbian wheezy with hardfp though, as most people will start using it.

Thanks,
Pete

[ken]

Okay, working fine with Debian wheezy  Thanks for the help. It would still be good to get a version for Raspbian wheezy with hardfp though, as most people will start using it.

Thanks,
Pete

Good that it works, sorry I mixed up Debian and Raspbian wheezy's, Linux is not my home field ...

/Ken

[zjean]

Hi all,
I am running Arch Linux on my Raspberry PI, together with Bass(.Net) on Mono.
When I play an MP3 file, it plays successfully however every second I hear a annoying sound, some kind of crack.
It looks to me that the buffer is too small, I tried to increase it several times, but it doesn't fix the problem.

[ken]

I have so far only tested streaming MP3 (BASS_StreamCreateURL) and I have no cracks or pops in the sound.

I'm running a WinForm application, (.NET Mono, C# 4.0 on "Soft-float Debian wheezy")

[Ian @ un4seen]

I am running Arch Linux on my Raspberry PI, together with Bass(.Net) on Mono.
When I play an MP3 file, it plays successfully however every second I hear a annoying sound, some kind of crack.
It looks to me that the buffer is too small, I tried to increase it several times, but it doesn't fix the problem.

Are you increasing the size of the stream buffer or the device buffer, ie. the BASS_CONFIG_BUFFER or BASS_CONFIG_DEV_BUFFER setting? If the former, you could try the latter. Note that needs to be done before calling BASS_Init (you can call BASS_Free and then BASS_Init again). Please also try monitoring what BASS_GetCPU says, to check whether it's struggling to decode the MP3 quickly enough.

[zjean]

...

Are you increasing the size of the stream buffer or the device buffer, ie. the BASS_CONFIG_BUFFER or BASS_CONFIG_DEV_BUFFER setting? If the former, you could try the latter. Note that needs to be done before calling BASS_Init (you can call BASS_Free and then BASS_Init again). Please also try monitoring what BASS_GetCPU says, to check whether it's struggling to decode the MP3 quickly enough.

Thanks, I increased the BASS_CONFIG_DEV_BUFFER and that seems to work. The CPU is now around the 13%.

[Ian @ un4seen]

A "hardfp" LIBBASS.SO build is now up in the package in the 1st post. If you give it a try, please report how you get on.

[gigi0ne]

hi ian.. it's possible to compile bassmix for hardfp?
thank's luigi

[Ian @ un4seen]

Yep, a "hardfp" version of BASSMIX.SO is now up in the package in the 1st post.

[gigi0ne]

hi ian, work perfect.. i think to pass my player on RPi, but using opus.. have you any roadmap for that?
thank's
luigi

[Ian @ un4seen]

Great to hear that the "hardfp" stuff is working well for you. BASSOPUS has now been added to the package too.

[ZXDunny]

Hi Ian - just a note to let you know that there may be a bug in

BASS_ChannelSetAttribute(Channel, BASS_ATTRIB_PAN, Panning);

using hardfp version...

A friend of mine is building my BASIC interpreter for raspberry pi in hardfp mode, and gets a floating point exception when that line is executed. The Channel var is HCHANNEL type and is correctly allocated, the Panning var is a float of type double. The compiler is FPC under lazarus. The softfp version works fine (though obviously won't work on a hardfp OS).

Any other info you need, let me know.

Oh, one other thing - very short sounds (such as very quick beeps of pure tone) are sometimes not played on the OpenPandora, or they ramp up in volume briefly at the start. This is using softfp under ARM linux. x86 linux doesn't appear to suffer this issue, but it cannot be ruled out that Pandora's sound hardware might be sub-par and nothing to do with your code. Just a heads-up.

Cheers,

D.