BlueZ-ALSA for OpenWRT compiled. #658
Replies: 17 comments 33 replies
-
|
There is nothing unusual in the log above. Perhaps the log from the bluealsa service might give some clue. Also, just to be sure, if you do |
Beta Was this translation helpful? Give feedback.
-
|
aplay ejemplo.wav plays OK through USB wired speakers: It seems like the sbc library doesn't code correctly... |
Beta Was this translation helpful? Give feedback.
-
|
And this is the log from bluealsa: |
Beta Was this translation helpful? Give feedback.
-
|
This is another bluealsa log (when playing the standard ALSA speaker-test) |
Beta Was this translation helpful? Give feedback.
-
|
@borine Thanks a lot for your quick answer :-) |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
'#include <endian.h>' is present on line 13 of the audio.c file, so I guess big-endian should be supported. Or maybe this line is just the problem? |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible for you to setup another BlueALSA-based device (preferably Linux x86) which will act as a BT sink? So you could connect OpenWRT device with this other device and capture BT data on it with e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, looking at the bluez sbc code, it appears that the both the If I'm right, then is actually more surprising that decoding is working on BE than it is that encoding is not working. This is because BlueALSA always uses S16_LE formatted PCM for SBC. I think that the application is supposed to set the To test this theory, in However, I cannot explain why the decoder is working on a big-endian device if the above theory is correct. |
Beta Was this translation helpful? Give feedback.
-
|
@borine @arkq Thanks a lot. |
Beta Was this translation helpful? Give feedback.
-
|
@raphikWasHere EDIT |
Beta Was this translation helpful? Give feedback.
-
|
I have also PKG_VERSION:=4.1.1 downloaded from https://github.com/Arkq/bluez-alsa/archive/v4.1.1/bluez-alsa-4.1.1.tar.gz For some reason my lines don't exactly match yours. But it does not matter; the line sbc.endian = SBC_LE follows the if block: Give me a while to compile it, upload it to the router and test it. I'm back soon. |
Beta Was this translation helpful? Give feedback.
-
|
@borine It works like a charm! (as it did before making any change) bluealsa-aplay verboses: |
Beta Was this translation helpful? Give feedback.
-
Well, I just don't understand this. The relevant code from the bluez sbc decoder is here: and clearly the output pcm stream has every pair of bytes written in reverse order depending on the value of |
Beta Was this translation helpful? Give feedback.
-
|
Let me share a wee trick to set the volume no matter what it's called. Of course, 28% is just an example. |
Beta Was this translation helpful? Give feedback.
-
|
This is way off topic now, but hey just for fun: Or if you don't care about efficiency, you could make it easier to read by avoiding ... and of course not all cards have the correct control for volume as first in the list. For USB then the first is 'Speaker', which is probably what you are using. For Intel PCH HDA it is "Master", which is a volume control, but you may prefer to use "Speaker" or 'Headphone' or 'PCM' depending on your use case; and for an i2c card using a Motorola DAC the first control is more likely to be something like 'DSP Program' which is definitely not a volume control. |
Beta Was this translation helpful? Give feedback.
-
|
In my opinion the relevant code from the bluez sbc decoder is equivalent to this: It seems to me that the order in which the bytes of the pcm stream are written depends on both the endianness of the machine and the value of sbc->endian. Two values for __BYTE_ORDER and two values for sbc->endian give four cases for which there are only two possibilities: bytes are written in direct order or in reverse order. For a __LITTLE_ENDIAN machine whose sbc->endian == SBC_LE the word order of an S16_LE stream consists on sending the LSB (s & 0x00ff) in 1st position and the MSB (s & 0xff00) in 2nd position. If the machine is __BIG_ENDIAN or sbc->endian == SBC_BE (only one of them being true), the order of the bytes to compose the S16_LE stream is reversed. Finally, if the machine is __BIG_ENDIAN and sbc->endian == SBC_BE (both of them being true), the order of the bytes to compose the S16_LE stream is reversed TWICE (Or what is the same, it stays the same). |
Beta Was this translation helpful? Give feedback.
-
|
The I will run some tests with extra debugging on a raspberry pi (armv7, little-endian) with I think this is important, because clearly BlueALSA needs to tell the SBC encoder that it is sending little-endian PCM on all architectures. But until the decoder behaviour is explained we cannot be certain that the method proposed here is correct. |
Beta Was this translation helpful? Give feedback.
-
|
So, on a little-endian host running Setting it to which correctly plays the audio. So on litlle-endian architectures my theory about |
Beta Was this translation helpful? Give feedback.
-
The simplest explanation for this phenomenon would be a bug in the bluealsa-aplay setup which "corrects" wrong endianess in the decoded SBC audio. I've been not tracking very carefully the discussion here, but @raphikWasHere have you checked the SBC decoder (the part which works with vanilla 4.1.1 code) with fixed |
Beta Was this translation helpful? Give feedback.
-
|
@raphikWasHere |
Beta Was this translation helpful? Give feedback.
-
|
I think that it should be possible to use QEMU to run SBC statically linked encoder/decoder on big-endian system. This might be helpful: https://til.simonwillison.net/docker/emulate-s390x-with-qemu Maybe I will find some spare time during weekend (but I can promise nothing). |
Beta Was this translation helpful? Give feedback.
-
|
The strange things are here: Maybe the correct way to initialize encoder/decoder is to pass BE as endianess? |
Beta Was this translation helpful? Give feedback.
-
sbcenc and sbcdec work only with Sun/NeXT audio S16_BE format, so they configure the encoder/decoder to use S16_BE on all architectures. That fits with my understanding. The issue I have is with default behaviour on big-endian where encoding appears to default to S16_BE (i.e. it does not work with BlueALSA) but decoding appears to default to S16_LE (i.e. it does work with BlueALSA). |
Beta Was this translation helpful? Give feedback.
-
If there is any test to be done on a big endian host, you can count on me. |
Beta Was this translation helpful? Give feedback.
-
Thank you! having a real BE device will be a big help. It's late here now and I am away for the weekend, but I will get back to this next week. We can work out a test plan then. |
Beta Was this translation helpful? Give feedback.
-
|
This is weird a lot: I open two ssh sessions against my OpenWRT host. In the 1st session I launch bluealsa in interactive mode so I can read its messages. In the 2nd session I launch several commands to connect my BT headset, play a wav file until it ends (it sounds ok), change the volume using amixer and play the same wav file again This is a copy and paste of commands and messages.
|
Beta Was this translation helpful? Give feedback.
-
|
I've found 2 issues in BlueALSA code that almost certainly relate to this:
I plan to prepare a new branch with fixes for these which I am hoping you will be able to test - but it will be next week before I have time to work on it. |
Beta Was this translation helpful? Give feedback.
-
|
@raphikWasHere Rather than pushing a new branch to github just yet, I've made a diff of changes against v4.1.1 which attempt to fix the bigendian errors reported so far. Default behaviour of SBC decoder/bluealsa-aplay is still a mystery to me; I'll look into that more once the results of the change here are known. Please apply this patch to your bluez-alsa v4.1.1 source directory: diff --git a/src/a2dp-sbc.c b/src/a2dp-sbc.c
index 1580db5..157c38a 100644
--- a/src/a2dp-sbc.c
+++ b/src/a2dp-sbc.c
@@ -181,6 +181,8 @@ void *a2dp_sbc_enc_thread(struct ba_transport_thread *th) {
/* initialize SBC encoder bit-pool */
sbc.bitpool = sbc_a2dp_get_bitpool(configuration, config.sbc_quality);
+ /* ensure libsbc uses little-endian PCM on all architectures */
+ sbc.endian = SBC_LE;
#if DEBUG
sbc_print_internals(&sbc);
@@ -228,6 +230,7 @@ void *a2dp_sbc_enc_thread(struct ba_transport_thread *th) {
if (errno == ESTALE) {
sbc_reinit_a2dp(&sbc, 0, configuration, sizeof(*configuration));
sbc.bitpool = sbc_a2dp_get_bitpool(configuration, config.sbc_quality);
+ sbc.endian = SBC_LE;
ffb_rewind(&pcm);
continue;
}
@@ -336,6 +339,8 @@ void *a2dp_sbc_dec_thread(struct ba_transport_thread *th) {
error("Couldn't initialize SBC codec: %s", strerror(errno));
goto fail_init;
}
+ /* ensure libsbc uses little-endian PCM on all architectures */
+ sbc.endian = SBC_LE;
ffb_t bt = { 0 };
ffb_t pcm = { 0 };
diff --git a/src/audio.c b/src/audio.c
index c384029..946acf1 100644
--- a/src/audio.c
+++ b/src/audio.c
@@ -102,13 +102,15 @@ void audio_scale_s16_2le(int16_t *buffer, size_t frames,
case 1:
if (ch1 != 0 && ch1 != 1)
while (frames--)
- buffer[frames] *= ch1;
+ buffer[frames] = (int16_t)htole16((int16_t)le16toh(buffer[frames]) * ch1);
break;
case 2:
if ((ch1 != 0 && ch1 != 1) || (ch2 != 0 && ch2 != 1))
while (frames--) {
- buffer[2 * frames] *= ch1;
- buffer[2 * frames + 1] *= ch2;
+ int16_t *ptr = &buffer[2 * frames];
+ *ptr = (int16_t)htole16((int16_t)le16toh(*ptr) * ch1);
+ ++ptr;
+ *ptr = (int16_t)htole16((int16_t)le16toh(*ptr) * ch2);
}
break;
default:
@@ -125,13 +127,15 @@ void audio_scale_s32_4le(int32_t *buffer, size_t frames,
case 1:
if (ch1 != 0 && ch1 != 1)
while (frames--)
- buffer[frames] *= ch1;
+ buffer[frames] = (int32_t)htole32((int32_t)le32toh(buffer[frames]) * ch1);
break;
case 2:
if ((ch1 != 0 && ch1 != 1) || (ch2 != 0 && ch2 != 1))
while (frames--) {
- buffer[2 * frames] *= ch1;
- buffer[2 * frames + 1] *= ch2;
+ int32_t *ptr = &buffer[2 * frames];
+ *ptr = (int32_t)htole32((int32_t)le32toh(*ptr) * ch1);
+ ++ptr;
+ *ptr = (int32_t)htole32((int32_t)le32toh(*ptr) * ch2);
}
break;
default:
diff --git a/src/shared/dbus-client.h b/src/shared/dbus-client.h
index 6d2dd49..dbe4531 100644
--- a/src/shared/dbus-client.h
+++ b/src/shared/dbus-client.h
@@ -12,6 +12,7 @@
#ifndef BLUEALSA_SHARED_DBUSCLIENT_H_
#define BLUEALSA_SHARED_DBUSCLIENT_H_
+#include <endian.h>
#include <poll.h>
#include <stddef.h>
#include <stdint.h>
@@ -170,12 +171,23 @@ struct ba_pcm {
/* 16-bit packed PCM volume */
union {
+#if __BYTE_ORDER == __LITTLE_ENDIAN
struct {
dbus_uint16_t ch2_volume:7;
dbus_uint16_t ch2_muted:1;
dbus_uint16_t ch1_volume:7;
dbus_uint16_t ch1_muted:1;
};
+#elif __BYTE_ORDER == __BIG_ENDIAN
+ struct {
+ dbus_uint16_t ch1_muted:1;
+ dbus_uint16_t ch1_volume:7;
+ dbus_uint16_t ch2_muted:1;
+ dbus_uint16_t ch2_volume:7;
+ };
+#else
+#error "Unknown byte order"
+#endif
dbus_uint16_t raw;
} volume;
|
Beta Was this translation helpful? Give feedback.
-
Searching the web I found that the bug has been around for years... https://bugs.freedesktop.org/show_bug.cgi?id=91359 |
Beta Was this translation helpful? Give feedback.
-
Ah, thanks. Following the link from there I see the the PA fix for white noise is the same as the one here, so that gives me more confidence that this is the correct approach for that issue. The volume control error is BlueALSA specific, because of implementation choices made here. Hopefully my patch will fix those (BTW this patch is untested on BE; I am relying on you to find any errors or omissions in it!). |
Beta Was this translation helpful? Give feedback.
-
|
I am cross compiling from scratch. This will take a little while. |
Beta Was this translation helpful? Give feedback.
-
|
@borine Once your patch applied and the source compiled, the results are:
|
Beta Was this translation helpful? Give feedback.
-
|
I've just pushed patch to new branch: https://github.com/arkq/bluez-alsa/tree/big-endian It's on top of current master, but the last commit can be easily applied on top of v4.1.1 tag. On top of previous patches I've added endianness correction for mSBC and FastStream. |
Beta Was this translation helpful? Give feedback.
-
|
@arkq Cross-compiling throws an error: Let me check for dependencies... |
Beta Was this translation helpful? Give feedback.
-
|
Yes... |
Beta Was this translation helpful? Give feedback.
-
|
Just to let you know, the patch for big-endian has been merged into the master branch. |
Beta Was this translation helpful? Give feedback.
-
|
OK. Thanks for notifying. |
Beta Was this translation helpful? Give feedback.
-
Hello,
After some failed attempts, I have managed to cross-compile BlueZ-ALSA 4.1.1 for OpenWRT.
The procedure is described here: https://github.com/raphikWasHere/bluealsa4openwrt/blob/main/bluez-alsa/readme
Scenario 1. Sending audio via bluetooth from an external source to wired speakers. It works as expected.
Plugging in two USB dongles to the router —one for bluetooth and one for audio— allows the router to receive audio from an external BT source to be heard through a pair of speakers.
Scenario 2. Sending audio via bluetooth from the router to a set of external headphones. Not working.
Plugging in one USB dongle to the router should allow the router to send audio to an external BT headset. It doesn't work. Only something similar to white noise is heard.
Debug throws:
Any help is gratefully welcome.
Beta Was this translation helpful? Give feedback.
All reactions