Topic: BASS for ARM Linux

[radio42]

Can you check what "Encoding.Default" is returned on your machine?

However, you might try this native overload:

Code: [Select]

IntPtr BASS_ChannelGetTags(int handle, BASSTag tags);You then have to marshal the returned IntPtr value into an Array of null-terminated strings.
The Un4seen.Bass.Utils class contains a few helpers to do so:
E.g.:
- "IntPtrAsStringAnsi" (this is actually what BASS_ChannelGetTagsICY and BASS_ChannelGetTagsHTTP are using)
- "IntPtrAsStringUnicode"
- IntPtrAsStringLatin1
- IntPtrAsStringUtf8orLatin1

I would assume, that maybe one of the two last once (IntPtrAsStringLatin1 or IntPtrAsStringUtf8orLatin1) might work.
If that's the case, please let me know, as I also don't have RPi Handy for testing...so that I might change the deafult handling...

Greets,
Bernd

[niston]

Hello Bernd!

On the Raspberry Pi, Encoding.Default returns System.Text.UTF8Encoding.

Using BASS_ChannelGetTags() works! I have to use Bass.Utils.IntPtrToArrayNullTermUtf8(ptrTags) though:

Code: [Select]

IntPtr ptrTags = Bass.BASS_ChannelGetTags(_stream,BASSTag.BASS_TAG_HTTP);
string[] httpInfo = Un4seen.Bass.Utils.IntPtrToArrayNullTermUtf8(ptrTags);

for (int n = 0; n <= httpInfo.GetUpperBound(0); n++)
{
    Console.WriteLine("HTTP Header: " + httpInfo[n]);
    // found station name ?
    if (httpInfo[n].Contains("icy-name")) { stationName = httpInfo[n].Replace("icy-name:", ""); Console.WriteLine("Found icy-name tag."); break; }
}

On a side note, might this be the same reason why umlauts in ICY tags (song/artist names) are displayed as ? on the Berry Pi?

[radio42]

That is then more than puzzling; as in case the Default Encoding is UTF8; this is what I also use in my intenal methods in that case.
So I am wondering, why ntPtrToArrayNullTermUtf8 would work, as that also uses UTF8...
Strange, however, I'll take a look what/where a difference might be!

[rdkartono]

Good day,

Ian, can i have debug version of ARM hardfloat libbass.so ?

So i have 1 Raspberry Pi2 (4cores, 1GB ram, 16GB microSD, latest raspbian) and several USB soundcards.
The idea is receiving PCM streaming using TCP ports with 22Khz, 16 bit, mono.
I mapped TCP port 5001 to USB soundcard 1, TCP port 5002 to USB 2, TCP 5003 to USB 3, and TCP 5004 to USB 4.
I opened BASS_StreamCreate for each USB (with proper Device IDs), and writing TCP received bytes to STREAMPROC callback.

Here are my findings :
1. When i use 1 usb soundcard only, all is OK.
    Raspi CPU usage around 5-10 %, RAM usage for this process is 3 MB.
2. When i plug 2 usb soundcards, still OK.
    Raspi CPU usage around 10-20 %, RAM usage for this process around 5 MB or so..
    But after long time (i mean hours), sometime suddenly sound become garbled, although the program is not crashed.
    Restarting the program / network / IP transmitter. The only cure is to reboot Raspi.
3. When i plug 3 USB soundcards, program started but sound is garbled all the time. Unusable at all.
4. When i plug 4 USB soundcards, definitely program can not started properly.
5. When I plug 4 USB soundcards, but only inited 2 of them, program can started. However after minutes, sound become garbled.

So if possible, i want to try using debug version of libbass.so (ARM hardfloat).
Do you need any toughts what might wrong ?

[Ian @ un4seen]

If I understand correctly, once the problem begins it won't stop until you reboot, eg. restarting the program won't fix it? If so, once it begins does it affect all playback, not only BASS? For example, is aplay affected? If aplay isn't affected, please check if playing the same file with BASS is affected, eg. with the "contest" example (from the Linux BASS package).

[rdkartono]

If I understand correctly, once the problem begins it won't stop until you reboot, eg. restarting the program won't fix it? If so, once it begins does it affect all playback, not only BASS? For example, is aplay affected? If aplay isn't affected, please check if playing the same file with BASS is affected, eg. with the "contest" example (from the Linux BASS package).

I have tried your question today. After sound became garbled, i tried APLAY playback to a simple WAV file, no sound output.
after reboot, APLAY the same file, can produce sound output again.

So.. is it ALSA problem ?

[Ian @ un4seen]

That does seem like it could be an ALSA issue. I guess another possibility could be a power issue, ie. a lack of it. How are you currently powering the USB soundcards? You could try a more powerful supply and/or a separate powered USB hub, and see if that helps.

[rdkartono]

That does seem like it could be an ALSA issue. I guess another possibility could be a power issue, ie. a lack of it. How are you currently powering the USB soundcards? You could try a more powerful supply and/or a separate powered USB hub, and see if that helps.

I powered the Raspi and 4 USB by using 5VDC 2.5A supply. Raspberry Pi power rating is only 700mA, so there is plenty of power for those USB.

I tried using another powered USB hub, stability results are worse than direct plug to raspberry.

Any ALSA setting that i need to check for enabling 4 USB devices ?

[Ian @ un4seen]

I'm not aware of any ALSA settings that would affect this. Did the same problem happen but more quickly when switching to a powered hub? If so, that would seem to suggest that the problem may well be power-related, ie. perhaps the hub was even lower powered. What happens if you split the soundcards, eg. 2 connected directly to the RPi and 2 via the hub?

[rdkartono]

I'm not aware of any ALSA settings that would affect this. Did the same problem happen but more quickly when switching to a powered hub? If so, that would seem to suggest that the problem may well be power-related, ie. perhaps the hub was even lower powered. What happens if you split the soundcards, eg. 2 connected directly to the RPi and 2 via the hub?

I have another theory : it is not power problem, but raspberry pi USB throughput rate problem. It seems dont have enough throughput to handle 4x TCP streams + 4x USB soundcards data.
So i think instead of using 4x stereo USB soundcard, i will try my luck on 1x 7.1 USB soundcards, and initializing it using SPEAKERS flag.
I will find the 7.1 soundcard first, and share the result in future.

[SteveS]

CD ripping on RaspberryPi 2

Previously, I have used code like this to rip CDs under Windows

Code: [Select]

HSTREAM hf;
DWORD r;
char buf[4096];

hf = BASS_CD_StreamCreate(0, nTrack, BASS_STREAM_DECODE);
if (hf != 0)
{
  while (BASS_ChannelIsActive(hf)==BASS_ACTIVE_PLAYING)
  {
      r = BASS_ChannelGetData(hf, buf, sizeof(buf));
      if (r == -1)
      {
          if (BASS_ErrorGetCode()==BASS_ERROR_ENDED) break;
          /* Handle error and clean up */
          ....
      }
      else
      {
          if (r!=0)
          {
               /* process data (pass to encoder, etc) */
               ...
           }
          else
          {
              /* data not (yet) available? */
          }
       }
   }
   BASS_ChannelStop(hf);
   BASS_StreamFree(hf);
}


I noticed that I was getting a lot of zero reads, which the Windows version doesn't seem to.
Are there things I could do to reduce this, or am I worrying over nothing?

SteveS

[Ian @ un4seen]

Yep, it's normal for BASS_ChannelGetData to return less than requested (even nothing) and it's nothing to worry about; you can just try again. In BASSCD 2.4.6, all CD reading is asynchronous, whereas decoding channels were previously synchronous. It will wait up to 100ms for more data for a decoding channel before it just returns whatever it can. That applies to both the Linux and Windows versions. The 100ms timeout could probably be made configurable, if that would be useful.

[SteveS]

The 100ms timeout could probably be made configurable, if that would be useful.

Probably not. Everything seems to be working, anyway, as I am gracefully(!) handling zero or a lower count.
My biggest issue is writing tags (particularly artwork) to my target MP3 files. I have C++ libs to do it, but they double the size of the code!

At least with it being a Pi B model 2 it has more RAM.

Thanks
/Steve

[jalbers]

Where can I find the musepack, ac3, tta, and spx add-ons for ARM Linux? I figured they'd be on the first post of this thread, but I'm not seeing them.

Those appear to be the only remaining add-ons that have equivalent x86 Linux builds but no ARM builds.

[Ian @ un4seen]

The add-ons have been ported to ARM Linux on an as requested basis, and you're the 1st to requests those ones ... I have put ports of them up in the 1st post now, but I haven't had time to test them yet. BASS_AC3/SPX in particular probably need some testing; BASS_MPC/TTA should be OK as they've already been ported/tested on Android (which is basically ARM Linux). Let me know if you have any trouble with them.

[jalbers]

I've done only light testing of these new plugins, but so far everything appears to be in working order. Thank you!

[JRfromFL]

Could you please also update the arm version of bassopus to libopus 1.1.2? I hope for less cpu load of the decoder 

Thanks !

[Ian @ un4seen]

The ARM Linux version of the latest BASSOPUS release (2.4.1.7) is now up in the 1st post.

[Ian @ un4seen]

The ARM Linux version of the new BASSALAC add-on (replacing BASS_ALAC) is now up in the 1st post.

[Ian @ un4seen]

The ARM Linux versions of the BASS 2.4.12 and BASSenc 2.4.13 releases are now up in the 1st post. Please note that BASS 2.4.12 slightly breaks back-compatibility in the BASS_CONFIG_NET_AGENT/PROXY options (BASS_SetConfigPtr now takes a copy of the provided string), so you should check how you're using those options, if you are.

[SteveS]

I'm using Raspian Jessie on a variety of Pi boards (Zero, B+, Pi2, Pi3).
Using a mix of USB audio, I2S DAC and so on is all fine.

However, I now want to be able to play over Bluetooth to wireless speakers or headphones.
(Obviously, I have USB BT adaptors for the relevant boards)

Bare ALSA doesn't seem to support this too well, and apparently requires pulse-audio or some such.
Is this the ONLY way to do it (through software), and if so, can anyone point me to an up to date HOWTO that is for Jessie rather than wheezy?

(If anyone knows how to get it to work without pulse, that would be great, I assume that pulse looks like a different device in ALSA, and hence will be compatible with BASS?)

/Steve

[Ian @ un4seen]

I'm unable to advise on setting up bluetooth, but regarding PulseAudio... when you install that, it would generally become the default ALSA output, so simply requesting the default device in your BASS_Init call would get the output to it. It will also appear separately in the device list with a driver="pulse" entry. You can run the DEVLIST example (included in the Linux BASS package) to see what devices BASS detects.

[nockiro]

Hi everybody!
First of all: Thank you for the work at that library, it's really great.

Though, I have a problem and I wonder if someone else has it, too.
I tried to use the Bass.NET-Library together with the hard-floating-point arm version of libbass.so with Mono on the quite new Raspberry 3 Model B, but everytime I want to run a program with a line of BassNet (I even tried it with the sample program described in the bass.net help file) the program crashes.

It doesn't matter which line I write nor where I put it in the code, I get always:

Code: [Select]

Unknown heap type: #GUlD
Unknown heap type: #Blop
Unhandled Exception:
System.BadImageFormatException: Bad method token 0x685e49f0.
  at bassmixchk.Program.SetupBassLibrary () <0x76b3c248 + 0x0002b> in <filename unknown>:0
  at bassmixchk.Program.Main (System.String[] args) <0x76b3bf50 + 0x00017> in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.BadImageFormatException: Bad method token 0x685e49f0.
  at bassmixchk.Program.SetupBassLibrary () <0x76b3c248 + 0x0002b> in <filename unknown>:0
  at bassmixchk.Program.Main (System.String[] args) <0x76b3bf50 + 0x00017> in <filename unknown>:0
For example, it crashes already on the following Codeline:

Code: [Select]

BassNet.Registration("MyEmail", "MyUsedKeyWitihALotOfChars");
I would say the library isn't loaded properly, but I put the .so in the /usr/lib as well as in the directory where I tried to start the application from, so I don't know where I could put it else.

Mono says it runs with the following version details:

Mono JIT compiler version 4.2.3 (Stable 4.2.3.4/832de4b Wed Mar 16 13:34:50 UTC 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen

System information like following:

   Operating System: Raspbian GNU/Linux 8 (jessie)
   Kernel: Linux 4.1.19-v7+
   Architecture: arm
   CPU: 1.2GHz 64-bit quad-core ARMv8 CPU

Obviously the same code with the windows related bass.dll works perfectly.

Please let me know if there is something I can do or if I forgot some important information - or if I did miss something obvious and only wasted your time, in that case, I apologize in advance.

Regards and thanks in advance,
nockiro

[Ian @ un4seen]

Are you definitely using the "hardfp" version of the libbass.so file? If so, to help narrow down what/where the problem is, please download the standard Linux BASS package and try building (after replacing the "makefile.in" file with the one in the ARM Linux package) and running an example (eg. the "contest" example) from that on your device.

[nockiro]

Hello Ian,
thanks for your reply. Yes, I was definitly using the "hardfp" version, the one which was in the "hardfp" folder :-D
I tried to build the package according to your instructions (using the standard linux package after replacing the makefile.in with the one in the ARM package), but I couldn't run an example because the build failed.
I think, in the second try the failure is more clearly, but I also added the first build try.
You can have a look under http://pastebin.com/WFpWX8pC

Any idea?

Thanks in advance for your help and regards,
nockiro