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.
-
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.
-
@borine It works like a charm! (as it did before making any change) bluealsa-aplay verboses:
|
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.
-
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.
-
@raphikWasHere |
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.
-
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.
-
@borine Once your patch applied and the source compiled, the results are:
|
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