No sound from Onkyo receiver about bluez-alsa

[borine]

I don't see any significant difference in the AVDTP stream control messages in any of the 4 onkyo tcpdump files, however one notable difference in the A2DP (SBC) packets is that in the gnome streams the first SBC packet has RTP sequence number 0 in all cases; whereas in the bluealsa streams the RTP sequence numbers of the first packet are 38976 (fd0) and 28487 (fd1) - the sequence number has decreased. I don't know if this can affect the Onkyo's behaviour, but its the only difference I have found so far. I'll keep looking.

[borine]

Looking at the server logs, it appears that the Onkyo is dropping the A2DP transport soon after it has been acquired. Perhaps it has a timeout waiting for the first codec frames to arrive after acquisition, or perhaps it just does not like Bluez. Perhaps the bluetooth logs will give more clues as to why that is happening.

The speaker-test log is slightly worrying. I have no idea why it hangs. The final "Stopping" message shows that the BlueALSA plugin has sent the thread cancel signal to its IO thread, but the lack of "IO thread cleanup" after that may indicate that the signal is not received. I cannot explain how that can happen; but, whatever, I think that this is a consequence of the above transport failure and not a cause of it.

[spamtree]

Thanks for the response. I thought I would report this in case anyone else runs across this problem. If there is any more information needed or you think that is helpful please let me now.

[borine]

Have you had success with this receiver when sending music from a phone or other OS (mac/windows)? If so, it would be useful to test it with pulseaudio or pipewire to see if they have more success than BlueALSA.

[spamtree]

I reported that it worked perfectly with other devices in the initial bug report. It works perfectly with ios, android 12/13, gnome Bluetooth setting on PC, and mate (blueman) on PC. On the PC with blueman that worked with the receiver I compiled bluealsa with debugging turned on and had the same result as the pi2. Blueman worked with sound setup for SBC or AAC. Did a quick search - found how to turn on debugging information for blueman and attached is the blueman and bluetooth debug log. Also repeated the bluealsa logs. Had the same results as on the pi2 - could not play any sound thru the bluealsa device to the Onkyo receiver. System was arch linux setup with pipewire. Pipewire was NOT running while running bluealsa (killed the x-server and used the console).
blueman_bluetooth.log
blueman.log
bluealsa_bluetooth.log
bluealsa_service.log
bluealsa_speaker-test.log

Files uploaded
blueman.log -- blueman-applet --loglevel debug
blueman_bluetooth.log -- bluetoothd -d (while blueman debug was running)
speaker-test worked fine with blueman running.

bluealsa_speaker-test.log - bluetoothctl, bluealsa-aplay -L, and speaker-test
speaker-test locked hard only could stop with pkill -KILL speaker-test
bluealsa_service.log - bluealsa running in debug mode -
/usr/bin/bluealsa -S -p a2dp-source -p a2dp-sink
bluealsa_bluetooth.log - bluetoothd -d while running bluealsa.

[arkq]

It works perfectly with ios, android 12/13, gnome Bluetooth setting on PC, and mate (blueman) on PC

blueman is just a graphical bluetootctl, but the underlying Bluetooth audio application might be either PulseAudio or PipeWire. I don't know how to debug them (in order to get meaningful information about differences between them and BlueALSA), but you might try to dump BlueZ communication. Please attach logs collected with such command (from the setup which works with Onkyo):

sudo dbus-monitor --system "sender=org.bluez" "destination=org.bluez"

Also, you might do the same thing on system with BlueALSA (it will be easier to search for potential differences). If potential issues with A2DP setup will be rulled out, then we will have to look into some differences with RTP audio packets.

[borine]

I think I can explain the application lockups.

When Bluez unexpectedly changes the transport state to "idle", the BlueALSA daemon releases the Bluetooth socket and stops the encoder I/O thread, but it does not release the client socket and FIFO.

So the plugin I/O thread continues to write samples to the FIFO until the FIFO becomes full, at which point the I/O thread becomes blocked. Meanwhile, the application calls snd_pcm_drain(), which waits for the I/O thread to empty the buffer - but that never happens because the I/O thread is blocked. So the application is now blocked in the call to snd_pcm_drain().

What happens now depends on the application. In the case of speaker-test a SIGINT from pressing Ctrl-C is caught, and the handler sets a flag which terminates the main loop on its next iteration. But the mainloop is blocked, so never gets as far as checking the termination flag.

@arkq Perhaps the poll() within bluealsa_drain() needs to include a timeout so that the plugin has an opportunity to abort the drain if requested by the application (eg if an application thread or signal handler calls snd_pcm_abort() during the call to snd_pcm_drain()). I'm not sure what condition to test for here yet, I need to do some more reading.

[EDIT]
It is also possible for the plugin call to bluealsa_dbus_pcm_ctrl_send_drain() to block forever if the server encoder IO thread is not running, because the server dbus client thread waits for the IO thread to signal a condition variable.
oops, that's not true - the "PCM drain" log message is skipped, but the client reply is still sent. So the only block forever condition I can find is the poll() call within the plugin bluealsa_drain()

[borine]

If I'm right about the cause of the application lockups, then the following simple patch should fix it for speaker-test, aplay etc that use snd_pcm_abort() in their signal handlers. Other applications may not be so lucky ...

diff --git a/src/asound/bluealsa-pcm.c b/src/asound/bluealsa-pcm.c
index 5556cb3..7a51b9d 100644
--- a/src/asound/bluealsa-pcm.c
+++ b/src/asound/bluealsa-pcm.c
@@ -691,7 +691,11 @@ static int bluealsa_drain(snd_pcm_ioplug_t *io) {
 		struct pollfd pfd = { pcm->event_fd, POLLIN, 0 };
 		while (bluealsa_pointer(io) >= 0 && io->state == SND_PCM_STATE_DRAINING) {
 			if (poll(&pfd, 1, -1) == -1) {
-				if (errno == EINTR)
+				 /* It is not well documented by ALSA, but if the application
+				 * has requested that the PCM should be aborted by a signal
+				 * then the ioplug nonblock flag is set to the special value 2.
+				 */
+				if (errno == EINTR && io->nonblock != 2)
 					continue;
 				break;
 			}

Of course this does nothing to address the main issue here, which is the failed A2DP transport with the Onkyo receiver.

[spamtree]

Interesting. I will give this a try in 2-3 days and get back with you the results. Have to deal with life now.

Thanks for looking into this problem.

[spamtree]

@arkq - Will also give that a try in 2-3 days. Thanks for the information!

[spamtree]

No improvement with patch. Same behavior. Here are the logs added aplay and bluez logs. Had to kill aplay and speaker-test and no sound. Thanks again for looking into this matter.

aplay.log
speaker-test.log
bluez-dbus-monitor.log
bluetooth.service.log
bluealsa.service.log

[spamtree]

@borine borine mentioned this issue Sep 25, 2023
Improve PCM plugin drain #667

Should I try this patch? If I try this patch should I remove the other patch?

Thanks.

[borine]

Had to kill aplay and speaker-test and no sound.

The "no sound" problem is most likely somewhere in the BlueALSA server, so my patch was not expected to fix that. The patch is supposed to enable you to kill aplay/speaker-test using ctrl-C instead of needing kill -KILL. It applies to the plugin shared library, so it is necessary to make install so that the patched shared library is placed into the correct directory for aplay or speaker-test to find it. Perhaps I should have placed an extra debug message in there so that we could see if the revised signal handling code is being called when ctrl-C is used. I will try to set up some different tests here to look at it again in case I have made a mistake in the code.

Improve PCM plugin drain #667
Should I try this patch? If I try this patch should I remove the other patch?

Sure, you can try it if you wish, it would be good to have feedback from a real test case. You would need to remove the other patch first, and make sure that the new plugin shared library is installed. Again, that PR does not attempt to fix the "no sound" problem. The idea is that the client application can not be stuck in a drain, so that after a certain amount of time the drain will stop and the application will "wake up" without needing to be killed. For speaker-test that may be a couple of seconds, because it uses a very large period size, but for aplay it should be less than half a second. The PR also includes the attempted ctrl-C fix from the first patch, so it should be easy to interrupt speaker-test instead of just waiting for it to finish.

I'm not very experienced at reading the Bluez logs, so that will need to wait until @arkq has time to go through them.

[arkq]

bluez-dbus-monitor.log

@spamtree, it seems that you've recorded D-Bus communication when using BlueALSA. Can you please record the same thing in a setup where audio works, e.g. on gnome?

[spamtree]

Okay I applied the patches from the Improve PCM plugin drain 667 and ran the tests again.

The most interesting development is that sound played for about 5 seconds and stopped. Also ctrl-c worked perfectly.

Attached are the logs - if the filename starts with bluealsa the files are the bluealsa logs and filename starts with gnome the files are the gnome logs. Sound worked perfectly with gnome. Thanks for looking into the problem.

gnome-bluez.log
gnome-bluetooth.service.log

bluealsa.service.log
bluealsa-speaker-test.log
bluealsa-bluetooth.service.log
bluealsa-bluez-dbus-monitor.log

[arkq]

@spamtree I will have to review all the dump files you've provided (thanks for that). I've looked at the D-Bus monitor logs, and there is one difference. Can you please try to run bluealsa system service with --a2dp-force-audio-cd option enabled? This will force 44100 Hz sampling rate. Also, check with and without --codec=-aac.

[spamtree]

Absolutely will do. May take a while for some reason cannot connect Onkyo receiver anymore. Will have to sort that out.

[spamtree]

Here are the logs with --a2dp-force-audio-cd. No sound with speaker-test. Had to hit ctrl-c three times to stop speaker-test. Had to reboot to restart bluetooth.service.

bluealsa-bluetooth.service.log
bluealsa.service.log
speaker-test.log
bluealsa-bluez.log

Below are the log files with the --codec=-aac and --a2dp-force-audio-cd options. Unable to connect to onkyo receiver. Bluetoothctl was disconnecting.

bluetoothctl-no-acc.log
btmon-no-acc.log
bluealsa-bluez-no-acc.log
bluealsa-bluetooth.service.no-aac.log
bluealsa.service.no-acc.log

[spamtree]

I have noted that when bluealsa does connect to the onkyo it always connects with AAC codec and in gnome I must select the SBC codec to enable sound. Removing the AAC codec from bluealsa causes a disconnection with the onkyo receiver. Actually if I select AAC codec in gnome the sound stops and the connection is broken to the onkyo. I have to clear the bluetooth pairing in onkyo receiver and repair again in order to connect the bluetooth after it crashes with AAC codec. Looks like to me the real problem is the onkyo receiver bluetooth is buggy. That is my opinion.

bluealsa-aplay -L
bluealsa:DEV=00:09:B0:1C:CD:D4,PROFILE=a2dp,SRV=org.bluealsa
    Onkyo TX-NR676 EE6F60, trusted audio-card, playback
    A2DP (AAC): S16_LE 2 channels 44100 Hz

[arkq]

If something is wrong with AAC then you can switch to SBC with CODEC option for PCM device. See bluealsa-plugins manual for reference. Start bluealsa service with AAC enabled.

[spamtree]

Thanks for the suggestion. Got it working see bluealsa-aplay -L

Did not work but it did connect. bluealsa locked completely and had to kill -KILL. Same results.

# bluealsa-aplay -L
bluealsa:DEV=00:09:B0:1C:CD:D4,PROFILE=a2dp,SRV=org.bluealsa
    Onkyo TX-NR676 EE6F60, trusted audio-card, playback
    A2DP (SBC): S16_LE 2 channels 44100 Hz

speaker-test -D bluealsa -f 44100 -c 2 

speaker-test 1.2.10

Playback device is bluealsa
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
[2347] D: bluealsa-pcm.c:1423: Getting BlueALSA PCM: PLAYBACK 00:00:00:00:00:00 a2dp
[2347] D: bluealsa-pcm.c:1176: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Setting constraints
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 570653
Period size range from 480 to 285327
Using max buffer size 570652
Periods = 4
[2347] D: bluealsa-pcm.c:546: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing HW
[2347] D: bluealsa-pcm.c:495: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Attempting to fix hw params buffer size
[2347] D: bluealsa-pcm.c:584: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: FIFO buffer size: 1024 frames
[2347] D: bluealsa-pcm.c:589: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Selected HW buffer: 4 periods x 524284 bytes == 2097136 bytes
[2347] D: bluealsa-pcm.c:620: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing SW
[2347] D: bluealsa-pcm.c:620: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing SW
[2347] D: bluealsa-pcm.c:620: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing SW
[2347] D: bluealsa-pcm.c:661: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Prepared
was set period_size = 142663
was set buffer_size = 570652
[2347] D: bluealsa-pcm.c:620: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing SW
 0 - Front Left
[2347] D: bluealsa-pcm.c:620: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing SW
[2347] D: bluealsa-pcm.c:629: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Changing SW avail min: 131071 -> 1
[2347] D: bluealsa-pcm.c:620: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing SW
[2347] D: bluealsa-pcm.c:629: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Changing SW avail min: 1 -> 131071
[2347] D: bluealsa-pcm.c:667: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Draining
[2347] D: bluealsa-pcm.c:374: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Starting
[2350] D: bluealsa-pcm.c:229: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Starting IO loop: 7
ALSA lib bluealsa-pcm.c:730:(bluealsa_drain) Drain timed out - possible Bluetooth transport failure
^C[2347] D: bluealsa-pcm.c:410: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Stopping
[2350] D: bluealsa-pcm.c:165: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: IO thread cleanup
^C[2347] D: bluealsa-pcm.c:661: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Prepared
 1 - Front Right
Time per period = 118.025413
[2347] D: bluealsa-pcm.c:620: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing SW
[2347] D: bluealsa-pcm.c:629: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Changing SW avail min: 131071 -> 1
[2347] D: bluealsa-pcm.c:620: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Initializing SW
[2347] D: bluealsa-pcm.c:629: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Changing SW avail min: 1 -> 131071
[2347] D: bluealsa-pcm.c:667: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Draining
[2347] D: bluealsa-pcm.c:374: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Starting
^C[2347] D: bluealsa-pcm.c:385: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Couldn't start PCM: Resource temporarily unavailable
[2347] D: bluealsa-pcm.c:410: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Stopping
^C[2347] D: bluealsa-pcm.c:410: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Stopping
^C[2347] D: bluealsa-pcm.c:599: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Freeing HW
[2347] D: bluealsa-pcm.c:457: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Closing

[arkq]

bluealsa locked completely and had to kill -KILL.

By bluealsa you mean the system service (bluealsa application)? If yes, if such lockup happens, can you please try to get backtrace of all threads in that process? Simply try to connects to it with gdb -p <PID-of-the-process> and type thread apply all bt.

[arkq]

Also, I would suggest to keep the --a2dp-force-audio-cd option all the time. In you first comment you've posted Onkyo receiver spec which says "20 Hz - 20 kHz (Sampling frequency 44.1 kHz)". Why would they mention sampling frequency here? I guess it might be better to stick with 44.1 kHz.

[spamtree]

Thanks will do. Have to get some work done but will get back to you. Yes the bluealsa.service and can't restart with systemctl restart bluealsa.service. Will get a backtrace. Thank you very much.

[borine]

Just quickly scanning through https://repairalmostanything.com/thread/767/never-wanted-onkyo-firmware I see that Onkyo receivers use Linux on the chip that performs audio decoding, networking and USB. So it is possible that Bluetooth functionality is provided by Bluez (although other Linux Bluetooth solutions exist). Now Bluez historically has a number of issues related to cacheing of codec infromation. AFAIK they are fixed in Bluez release 5.65, but if your Onkyo is using Bluez then it is very likely to be an older version than that.

The Onyo documentation should mention what open-source software it is using (if any) to comply with the licensing requirements. If it does use Bluez then I think some of the behaviour you see may be because the Onkyo has cached codec info from the first time your computer was paired with it (using Gnome or Blueman), so when you later change the audio agent on your computer you get different available codecs and different codec configurations, but the broken Blluez cache does not pick up on those changes so the transport fails. There may be a workaround, but it would require cllearing the Bluez cache. Unpairing and/or re-pairing a device does not clear the cache on broken releases of Bluez.

[borine]

BTW

speaker-test -D bluealsa -f 44100 -c 2

You need to use
speaker-test -D bluealsa -r 44100 -c 2

to force the output sample rate to 44100

[borine]

Here's my interpretation of what is happening in the last speaker-test log above.

Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise

speaker-test is generating pink noise sampled at 48000Hz

Using max buffer size 570652
Periods = 4

speaker-test has set a period size of 570652 / 4 = 142663 frames.
This translates to 2972 milliseconds at 48000Hz, so bluealsa will use a drain
timeout of just over 3 seconds.

ALSA lib bluealsa-pcm.c:730:(bluealsa_drain) Drain timed out - possible Bluetooth transport failure

The bluealsa plugin is unable to drain the buffer because the bluealsa server is not responding. It blocks for the timeout period (just over 3 seconds in this case) then reports that error.

^C

I think if you wait 3 seconds here then the ^C is not necessary; but as a result of this speaker-test sets a flag so that its mainloop is stopped on the next iteration, and future ALSA blocking calls (write, drain) to this PCM return immediately with the error EINTR.

[2347] D: bluealsa-pcm.c:410: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Stopping

As a result of the drain timeout, the bluealsa plugin now stops the PCM

^C

not necessary - the first ctrl-c told speaker-test to set its stop flag, this one and subsequent presses of ctrl-c have no effect.

1 - Front Right

speaker-test ignores the error code returned by the drain function and proceeds to send noise to the second channel. This time it does not call drain() because its stopping flag is set. Had you not pressed ctrl-c earlier, then it is possible speaker-test may become blocked at this point because the attempt to write will block if the buffer is full. If so ctrl-c here will unblock it (but I don't think the buffer would have filled yet).

Time per period = 118.025413

The speaker-test prints timing statistics before leaving its mainloop.

^C

same as above

[2347] D: bluealsa-pcm.c:385: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Couldn't start PCM: Resource temporarily unavailable

speaker-test tries to drain the PCM one last time before exiting. The bluealsa plugin tries to send a control message to the server to resume the PCM; but the server is no longer reading control messages, and that error results.

[2347] D: bluealsa-pcm.c:410: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Stopping

So now the plugin makes sure that the PCM is stopped, which is a no-op because it is not currently running

^C

same as above

[2347] D: bluealsa-pcm.c:410: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Stopping

Finally speaker-test closes the PCM. So again the plugin makes sure the PCM is stopped (still a no-op)

^C

Same as above

[2347] D: bluealsa-pcm.c:599: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Freeing HW
[2347] D: bluealsa-pcm.c:457: /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink: Closing

the bluealsa plugin cleans up its resources and then speaker-test exits with exit code 0

[spamtree]

I will try to address the questions and I followed the recommendations. Changed settings on speaker-test and bluealsa as recommended. No information in the onkyo manual about open source for bluetooth.

speaker-test has stopped for 30 minutes with the last message being ->

ALSA lib bluealsa-pcm.c:730:(bluealsa_drain) Drain timed out - possible Bluetooth transport failure

Had to hit Ctrl-C four times to stop speaker test and was able to restart bluealsa.service after killing the bluealsa process (kill -KILL bluealsa_process).

dmesg log showed that bluetooth killed the connection to the onkyo.

Bluetooth: hci0: killing stalled connection 00:09:b0:1c:cd:d4

I have to clear the bluetooth pairing on the onkyo and the laptop in order to connect again to the onkyo.

attached are logs.

dmesg_hci0.log
bluez.log
bluetooth.service.log
bluealsa.log
speaker-test.log
gdb.log

[arkq]

Thanks for the gdb.log. Unfortunately, there are no debug symbols there.... Please check if binary was built with debug symbols (with debug_info, not stripped), e.g.:

$ file build/src/bluealsa
build/src/bluealsa: ELF 64-bit [...] for GNU/Linux 3.2.0, with debug_info, not stripped

If it's not, please try to add -g to CFLAGS before compiling. If executable has got symbols, please go to the directory from which you've run make and from this directory run gdb -p ..... This should allow gdb to load symbols and source files to generate verbose backtrace.

[borine]

Had to hit Ctrl-C four times to stop speaker test

@arkq - it looks like the server glib client event loop may be locked up, the speaker-test log above appears to indicate that the plugin is stuck waiting for a reply from the server for the Drop command, then again for the Resume command,etc. Do you think there should be a timeout in the client code when waiting for a command reply? If so I could push another commit to PR #669

[arkq]

Do you think there should be a timeout in the client code when waiting for a command reply?

To be honest I'm not sure. I don't know how long we should wait, 1 second or maybe less? I'd like to try to fix the server first, so such lockup will not happen. But anyway, maybe timeout on the client side is a good idea as well... dunno :D

[borine]

OK, I'll leave that for further consideration, perhaps I can come up with some rationale for a specific timeout value for each command. I'll also look into the possible usefulness of skipping other actions, in addition to drain, when the ioplug nonbock value indicates an abort request from the application.

[spamtree]

Thanks for the gdb.log. Unfortunately, there are no debug symbols there.... Please check if binary was built with debug symbols (with debug_info, not stripped), e.g.:

$ file build/src/bluealsa
build/src/bluealsa: ELF 64-bit [...] for GNU/Linux 3.2.0, with debug_info, not stripped

If it's not, please try to add -g to CFLAGS before compiling. If executable has got symbols, please go to the directory from which you've run make and from this directory run gdb -p ..... This should allow gdb to load symbols and source files to generate verbose backtrace.

Pretty sure I didn't do the debug symbols and thanks for the tip on how to turn it on. Will do. This is interesting. Learning a lot.

[borine]

Bluetooth: hci0: killing stalled connection 00:09:b0:1c:cd:d4

The only relevant search results I get for this error suggest the underlying cause is possibly a kernel bug related to power-save mode, see for example https://bugzilla.kernel.org/show_bug.cgi?id=203535

That does not explain why it is specific to the Onkyo, nor how pipewire can work correctly with the same USB dongle, so it may not be the problem here.

[borine]

Here's a review of my interpretation so far of the logs, before I leave this alone for a few days.

The encoder io thread ("ba-a2dp-sbc") is blocked in poll() waiting for the BT socket to become writeable. I can find no clue in the logs as to why the socket is blocked.

The client event handler thread ("pool-spawner") is blocked in pthread_cond_wait() waiting for the drain to finish. But the drain never finishes because the encoder thread is blocked.

The main thread ("bluealsa") is blocked in pthread_cond_wait() but there is no clue as to why or where. Debug symbols so that we can see the function call stack are required before any progress can be made on debugging this. Originally I thought this thread might be waiting for the "stopping" flag, but now I see that there are no events in the logs that may have triggered the transport to be stopped. So this is a mystery. Perhaps memory corruption, perhaps the condition variable is actually inside the glib main loop and we are looking at a glib bug, or any other theory you like.

[spamtree]

More info. Hopefully I did this correctly. I tried to follow the directions given but if I did not collect the right logs or did something incorrect please let me know. Thanks
gdb.log
speaker-test.log
bluetooth.service.log
bluealsa.log

I noted that I forgot the the bluez output. I will repeat and send that log also.

[spamtree]

Okay. I leave the last post up but did not follow the directions correctly. I was supposed to run "gdb" once bluealsa crashed. Well I started gdb session while bluealsa for running (bluealsa did not crash). For the previous post and this post I installed the latest patch from "Improve PCM plugin drain #667". The good news is bluealsa no longer crashes when attempting to play sound, but still no sound. So I don't have gdb log since bluealsa did not crash. speaker-test did not crash either. Another observation - I don't have to reset the onkyo receiver and pair again to connect to the device.

bluealsa:DEV=00:09:B0:1C:CD:D4,PROFILE=a2dp,SRV=org.bluealsa
    Onkyo TX-NR676 EE6F60, trusted audio-card, playback
    A2DP (SBC): S16_LE 2 channels 44100 Hz

New logs below.

speaker-test.log
bluealsa.log
bluez.log
bluetooth.service.log

[borine]

bluealsa did not crash

Actually, it is not locked up, but it has still failed. This isn't so obvious now using speaker-test because speaker-test ignores the error returns from the ALSA PCM and just continues to loop. However, you still get this in the speaker-test log:

ALSA lib bluealsa-pcm.c:744:(bluealsa_drain) Drain timed out: Possible Bluetooth transport failure

These logs are using AAC, whereas previously we had SBC logs. I don't know how significant that is, but the bluez dbus messaging is now different. I'll read through these in detail next week. You said that pipewire/gnome also fails with AAC, so perhaps we should stick with SBC for testing now so that we can compare logs between pipewire and bluealsa.

For me, it would be easier to follow if aplay was used for testing rather than speaker-test. That way we would have a log of a simple open-write-drain-drop-close sequence from the client to help spot any anomalies. Something like

aplay -D bluealsa /usr/share/sounds/alsa/Front_Center.wav

Also, if at all possible, building the current master branch sources and using that for testing would make things a little easier, although I appreciate that is not always possible depending on your build and test environment, distribution, etc.

Thanks for sticking with this, I really hate to think that pipewire can succeed where bluealsa fails,

[spamtree]

That was my mistake I was trying to disable AAC by using .asoundrc.conf but that didn't work. I just noticed it and was about to post the new log. The log with SBC is the same as with AAC. Will get some more logs today.

I noticed this in bluetoothctl as soon as play is started and dmesg errors are gone also.

[CHG] Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0 State: active
[CHG] Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0 State: idle

Thanks for the looking into this matter.

It is going to take a little time to build the master branch but will do. I done something similar in the past and you folks have excellent instructions so it should be doable even with my limited skill level.

[spamtree]

When compiling from the master branch did I need to apply the drain patches?

In most of the logs when aplay is started device is active and then switches immediately to idle.

More logs with SBC and aplay. The same effect if the "wav" file is 48000 Hz or 44100 Hz. Expect when playing the 44100 Hz file aplay requires Ctrl-C to return to command prompt. Note the 44100 Hz file was longer than the 48000 Hz file. Not sure if that has any effect, but the bluealsa logs look similar.

Logs:

bluealsa.service-aplay-48000Hz-file.log
bluealsa.service-aplay-44100Hz-file.log
bluetooth.service.log
aplay-48000.log
aplay-41000.log
bluealsa.service.log
bluez.log

[borine]

OK, so these logs are much easier to read - thankyou!

first the aplay-48000 run.

The aplay log aplay-48000.log is exactly as I would expect for a working system. The BlueALSA plugin has successfully played out the whole 1 second file and cleaned up correctly.

The bluealsa service log bluealsa.service-aplay-48000Hz-file.log again shows the server correctly setting up the A2DP transport, play out the audio, then cleaning up.

So as far as BlueALSA is concerned this file was played correctly. The only thing that looks slightly odd is that the Resume command occurs at 12:54:58 but the drain does not complete until 12:55:00, so it looks like 2 seconds of audio played. However, that may be rounding error in the timestamps, so its not really a big concern. So I cannot explain why no sound was heard from the Onkyo.

Now the `aplay-441001 run.

The aplay log aplay-41000.log actually shows 2 separate runs of aplay, process id 3864 then process id 3949. In both runs aplay appears to stall while playing the audio - I guessing you used Ctl-C to terminate them both. This tells me that the bluealsa server is not reading from the PCM audio pipe.

The bluealsa service log bluealsa.service-aplay-44100Hz-file.log shows that the server corretly setp up the A2DP transport, but 5 seconds after the encoder started to play out the audio to the bluetooth socket, Bluez changed the transport state to "Idle" causing the bluealsa server to close the transport before the audio was finished. 25 seconds after that the client connection was closed - I'm guessing that's when you used Ctl-C on aplay.

The log bluez.log appears tp confirm that Bluez changes the transport state to idle 5 seconds after activating it. The consistency with which this happens suggests to me that somewhere in the Bluez/Bluetooth layers there is a timeout of 5 seconds waiting for something that apparently BlueALSA is not doing but Pipewire does.

I'm guessing the test file Track06.wav is longer that 5 seconds, and that is the real difference between these test runs, the different sample rates are not relevant. If you have a test sample at 48000Hz longer than 5 seconds, that would prove it.

I can't spend any more time on this now, but will look at it again later next week.

[spamtree]

You are correct with a test sample wave file at 48000Hz longer than 5 seconds the behavior is the exactly the same.

Also I waited until the song was completed before hitting Ctrl-C. The song was about 5 minutes so I waited 10 minutes before hitting Ctrl-C.

[borine]

When compiling from the master branch did I need to apply the drain patches

No, please initially use the source without any changes, to give a baseline. I may ask you to apply the patch in #670 later, but only if we can trigger the lockup again first. You will probably need to enable aac, and also please make sure you enable debug. If you are able to successfully build, and install, and then connect to the Onkyo, then I have some more tests I would like to you to run.

I now know that the lack of sound from the Onkyo is caused by it sending a AVDTP SUSPEND command, which causes bluez to force the A2DP transport to the idle state. I need to know if that same command is also sent when using pipewire/gnome, and then try to work either why not, or else how pipewire, or some other component of the gnome desktop, deals with it.

But first some logs using bluealsa master branch; using aplay, then using speaker-test. While aplay is blocked, and before pressing control-C, please try to produce the gdb backtrace. Hopefully your manual build of the master branch will have gdb debug symbols as that is the default. If speaker-test also gets blocked, then please also produce the gdb backtrace.

Be prepared though, that depending on why the Onkyo is sending that suspend command, it may turn out to be impossible to use bluealsa with it. I'm looking through the pipewire source code and haven't found any hints yet, so at this stage I really don't know whether we can fix this.

[borine]

After some more reading of the Bluetooth specs, I'm now thinking the underlying problem here is a combination of a bug in the Onkyo firmware, and the use of stale cached SEP configuration data by Bluez. Both are outside of the control of Bluealsa, so we cannot code a workaround for it. However, if the cache problem exists only on the Bluez side (and not also on the Onkyo side) them it may be possible to fix it by clearing the Bluez cache.

From the Bluetooth GAVDP and AVDTP specifications, it is clear that the AVDTP SUSPEND command is used only when one device wishes to either change stream parameters after streaming has started, or to terminate the stream. In the first case it should be followed by a AVDTP RECONFIGURE command and in the second by a AVDTP CLOSE command. The bluetooth.service logs show that neither of these are received from the Onkyo, which is why I think the Onkyo is buggy.

I see no cause for the Onkyo to close the stream, so I assume it wishes to change the stream parameters. Why would the Onkyo wish to do that? The only reason I can think of is the stream is started using a cached configuration created when using Gnome/Pipewire, (that's why it works with your Gnome setup) but Bluealsa is sending codec frames with a different configuration. So the Onkyo cannot accept them and tries to request that the configuration be changed, but fails. According to version 1.3 of the GAVDP spec this is an error anyway, because only the source node (Bluez/BlueALSA) can make this request, not the sink (Onkyo). That restriction did not exist in earlier versions of the spec, and was added as an erratum in version 1.3

To clear the Bluez cache it is best to unpair the devices first (not always necessary, but a clean start means there is less that can go wrong). I previously posted a method for clearing the cache here: #554 (comment)

When you restart the bluealsa service at the end of the procedure please make sure that bluealsa is running with all the codecs you want to use enabled, as changing them later may re-introduce this problem. After pairing with the Onkyo, try with aplay and a wav file of more than 10 seconds. If this still produces no sound, then please produce a log from the bluetooth service showing from just before aplay is started until it has run for at least 10 seconds or so. If the log message
profiles/audio/avdtp.c:avdtp_parse_cmd() Received SUSPEND_CMD appears then it is likely that the issue is with cacheing on the Onkyo. Perhaps a factory reset of the Onkyo will clear that, if not then I'm afraid I am out of ideas.

[EDIT] *** see next post

[borine]

One more idea - possibly more convincing than the last one. The consistent interval of 5 seconds between acquiring the A2DP transport and receiving the AVDTP SUSPEND command has been bugging me. There is no mention of such a time delay, or specific use of the suspend command in that way, in the Bluetooth specs. So I looked through the Bluez A2DP source code.

When used on a sink (eg the Onkyo), on receipt of a AVDTP START command Bluez sends back a confirmation response, changes the corresponding transport state from IDLE to PENDING, starts a 5 second timer, then waits for some local application to acquire the transport. If acquisition does not happen within the 5 seconds it changes the transport state back to IDLE and sends a AVDTP SUSPEND command to the source.

Now look at the bluetooth.service logs on our bluealsa A2DP source host. When aplay starts playback, bluealsa asks Bluez to acquire the transport, causing Bluez to send a AVDTP START command to the Onkyo. Bluez immediately recieves a confirmation response and so changes the transport state to ACTIVE, causing bluealsa to start sending out encoded audio frames. 5 seconds later Bluez receives a AVDTP SUSPEND command from the Onkyo, causing it to change the transport state to IDLE. Bluealsa then stops sending audio and so aplay becomes blocked waiting for the ALSA ring buffer which has become full.

Can that just be coincidence, or is it possible that the Onkyo is using Bluez, and is waiting for some event to start the playback of the incoming stream? Perhaps some button press, perhaps some other Bluetooth event such an AVRCP command or other? I don't see any other Bluetooth profile active in the gnome-bluez log so I don't know how gnome is managing to persuade the Onkyo to play the stream, but this theory does at least explain the troubling 5 second interval.

[borine]

@spamtree I've created a test A2DP sink using BlueALSA, modified so that the bluealsa daemon does not acquire the transport when a new incoming stream arrives. Tested against a source using BlueALSA, and the bluetooth.service log on the source looks exactly like yours. So I am now convinced the problem is that the Onkyo is not starting a bluetooth playback application when the incoming stream arrives. To work out how Gnome is different I would need to see the bluetooth.service log for a working Gnome session from the time just before aplay is started until the file is played out (a short file, but more than 10 seconds, would be best). You could use the original 4.1.1 BlueALSA build for this. as we know that is working, or a build from the latest master branch if you have it, whichever is the easiest for you to set up. oops, no bluealsa needed for this test - sorry for any confusion caused!

[spamtree]

Wanted to let know that I'm still here but have a lot of work to do. I have installed the bluealsa git master and was running some tests yesterday. The results were the same timeout after 5 seconds and bluealsa did not crash (no gdb info). After reading your posts what I have been working on is capturing some logs for a working gnome session and trying to crash the onkyo bluetooth stack. What is interesting is the bluetooth.service logs are almost empty even with debug turned on. The bluetooth connection appears to be managed by wiremanager. So I have been playing around with getting debugging logs from wiremanager. I think I understand how to do this after reading Debugging Pipewire

Will work on getting some logs. If I am going in the wrong direction let me know. Thanks.

[borine]

The bluetooth connection appears to be managed by wiremanager.

I've never heard of wiremanager. There is a section https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting?version_id=8e027b3eaf9e0628471d5cacc31a18b5dff0390f#bluetooth-traffic-dump on how to use btmon, and that info would be useful, but the file will be huge, so I was hoping that just looking at the bluetooth debug log would be enough to give a clue.

bluetooth.service logs are almost empty even with debug turned on

That's weird, I wonder if gnome is somehow turning off the debug option. What method do you use to enable debug in bluetooth?

While bluetooth is started, and producing these near-empty logs, please can you run:

ps -ef | grep bluetoothd

and check that the output shows the -d option, something like

root      127755  1 1 14:54 ?    00:00:00 /usr/lib/bluetoothd -d

[spamtree]

Whoops! Didn't write the correct systemd override unit file for bluetooth.service. Thanks for the tip that is fixed. Attached is gnome.bluetooth.service.log before aplay and after aplay was completed. If I run the aplay command again the gnome.bluetooth.service.log was the same. Will add a new bluealsa.bluetoothd.service.log before and after aplay. If something does not look write let me know. I can repeat everything quickly now. Thanks!

bluealsa.service.log
bluealsa.bluetooth.service.log
bluealsa.aplay.log
gnome.aplay.log
gnome.bluetooth.service.log

[borine]

Thanks for the new logs. They confirm that pipewire/gnome are not sending any "special" bluetooth control commands to the Onkyo to start the stream, the command sequence is the same as used by BlueLASA. However, comparing with earlier logs I noticed one interesting difference: when using pipewire the stream configuration "blob" is different than when using BlueALSA. The Pipewire stream uses "21150228" which decodes to:

SBC <hex:21150228> {
  sampling-frequency:4 = 44100
  channel-mode:4 = JointStereo
  block-length:4 = 16
  subbands:2 = 8
  allocation-method:2 = Loudness
  min-bitpool-value:8 = 2
  max-bitpool-value:8 = 40
}

Note the allocation method: "Loudness"

Whereas the BlueALSA stream configuration is reported in the logs as:

Oct 22 20:17:40 travel bluealsa[1397]: codec-sbc.c:264: SBC setup: 44100 Hz JointStereo allocation=SNR blocks=16 sub-bands=8 bit-pool=40 => 256331 bps

Note the allocation method is "SNR"

So perhaps we can persuade BlueALSA to use the "Loudness" allocation method. I have no idea if this will work, but please can you try, while running bluealsa (do not use --force-audio-cd for this test, allow bluealsa to use the format defined in the codec configuration):

aplay -D bluealsa:CODEC=sbc:21150228  Track06.wav

That command requests that bluealsa use the same SBC configuration as is used by pipewire on the Onkyo. So perhaps that will persuade the Onkyo to play the stream.

[spamtree]

Wow! That did it! You are great!

Thanks!!!

[borine]

Thats good news. You could make it easier to use by creating a ALSA configuration entry in either ~/.asoundrc or /etc/asound.conf. I suggest:

pcm.onkyo {
	type empty
	slave.pcm "bluealsa:DEV=00:09:B0:1C:CD:D4,CODEC=sbc:21150228"
	hint.description "Onkyo TX-NR676 EE6F60"
}

Then you can use it as aplay -D onkyo Track06.wav

It may be possible to also get AAC working using the same trick if we can find the correct configuration blob in the bluez-dbus-monitor.log from a working AAC stream using Pipewire/Pulseaudio or whatever.

I will continue to look into this to see if there is anything at all thar BlueALSA can do to identify when a device is ignoring ta requested codec configuration change.

[arkq]

I will continue to look into this to see if there is anything at all thar BlueALSA can do....

I have not spotted that before, but in the bluealsa logs we've got:

Oct 10 21:01:20 travel bluealsa[1456]: bluez.c:280: A2DP peer capabilities blob [len=4]: ffff0228                                                                                                                    
...
Oct 10 21:01:21 travel bluealsa[1456]: bluez.c:420: A2DP Source (SBC) configured for device 00:09:B0:1C:CD:D4                                                                                                        
Oct 10 21:01:21 travel bluealsa[1456]: bluez.c:423: A2DP selected configuration blob [len=4]: 21150228                                                                                                               
Oct 10 21:01:21 travel bluealsa[1456]: bluez.c:425: PCM configuration: channels: 2, sampling: 44100                                                                                                                  
...
Oct 10 21:02:52 travel bluealsa[1456]: ba-transport.c:1949: Created new IO thread [ba-a2dp-sbc]: A2DP Source (SBC)                                                                                                   
Oct 10 21:02:52 travel bluealsa[1456]: codec-sbc.c:262: SBC setup: 44100 Hz JointStereo allocation=SNR blocks=16 sub-bands=8 bit-pool=40 => 256331 bps                                                               
Oct 10 21:02:52 travel bluealsa[1456]: a2dp-sbc.c:222: IO loop: START: a2dp_sbc_enc_thread: A2DP Source (SBC)

$ ./utils/a2dpconf sbc:21150228
SBC <hex:21150228> {
  sampling-frequency:4 = 44100
  channel-mode:4 = JointStereo
  block-length:4 = 16
  subbands:2 = 8
  allocation-method:2 = Loudness
  min-bitpool-value:8 = 2
  max-bitpool-value:8 = 40
}

but ... allocation=SNR ...

[arkq]

but ... allocation=SNR ...

It seems that it is only due to a bug in the sbc_print_internals() function. So I wonder why bluealsa:CODEC=sbc:21150228 worked....

EDIT: Fix pushed to master

[borine]

So I wonder why bluealsa:CODEC=sbc:21150228 worked....

I think it is because that request causes bluealsa to invoke org.bluez.MediaTransport1.SetConfiguration(). Without it the local endpoint uses the configuration set by the Onkyo and I suspect that, possibly because of cache management issues, the Onkyo is not correctly applying that configuration to its own endpoint, leading to failure when the first codec frames arrive. By calling SetConfiguration() itself, bluealsa forces the Onkyo to change the configuration of its own endpoint so that both ends have the same configuration.

To test that idea we would need some way of knowing what the actual configuration set on the Onkyo endpoint is; perhaps a org.freedesktop.DBus.Properties.Get() call would do that? I don't know enough about the workings of A2DP or Bluez to know how this situation can happen, or how to test for it.

[arkq]

To test that idea we would need some way of knowing what the actual configuration set on the Onkyo endpoint is

There is AVDTP command AVDTP_GET_CONFIGURATION which should query current configuration for given SEP. But I'm not sure whether it's possible to call such request via BlueZ without some code modifications. There is a avdtp_get_configuration() function but it is only used by the test tool.

[borine]

@spamtree now that bluealsa has successfully configured the A2DP stream, it is possible that the Onkyo has updated its cached configuration. One way to test that is to try bluealsa without specifying a specific config:

aplay -D bluealsa Track06.wav

Could you try that to see if it now works? And if it does, then try with Gnome again to see whether that still works.

[spamtree]

@borine Thanks for the .asoundrc, I was working on one but yours is much better.

AAC does not work with gnome either and when I looked at the configuration for the onkyo in gnome the selection for AAC was missing completely. It was there at one time. Don't have a clue why it is missing now.

Before I saw the above messages - I started changing the sound configuration in gnome for the onkyo receiver playing with higher quality SBC codecs. Don't have a clue why I did this but messing around. Anyway sound played fine with gnome, but when I went back to bluealsa on a different pc, no sound in bluealsa and then no sound in gnome! Well cleared all the bluetooth caches on the computers and then cleared the bluetooth caches on the onkyo and reset the onkyo receiver. I first setup bluealsa but NO sound. Then I setup gnome and sound worked. Then tried bluealsa again and sound returned! No more messing with codecs will stick with plain SBC. Not sure but once the cache is setup on the onkyo I guess one can't change the codec (only a thought but no way I can prove it). Onkyo is probably buggy.

@borine
After running
aplay -D bluealsa:CODEC=sbc:21150228 Track06.wav

Then running
aplay -D bluealsa Track06.wav

Both command played sound!

Hope this helps. Had logs but did not send them since sound is working again.

[spamtree]

Here are the logs that I collected from the above session.

sound-gnome-bluez.log
sound-gnome-bluetooth.service.log
sound_CODEC-sbc-21150228-bluetooth.service.log
sound_CODEC-sbc-21150228-bluealsa.service.log
nosound-CODEC-sbc-21150228-bluetooth.service.log
nosound-CODEC-sbc-21150228-bluealsa.service.log

[spamtree]

You good folks have taught me a lot about debugging bluetooth sound problems. I have learned how to capture bluetooth logs and slowly learning how to read these logs but still way over my head. I think my initial bug request was probably inaccurate. I will explain.

I returned from work today and wanted to check and see if sound was still working. Started the two computers and No sound on bluealsa or gnome. I noted the same 5 sec delay - state changing to active to idle on both bluealsa and gnome. I got sound working on gnome after restarting bluetooth.service and reconnecting to the onkyo. Decided to pair an iPhone to the onkyo and audio played nicely.

I decided to NOT reset all the bluetooth caches, NOT unpair and repair bluetooth, and NOT reset the onkyo. I reviewed the previous logs and compared them with new logs today and noted something interesting with the file descriptor. The file descriptor had to be fd0 for sound to play with bluealsa to the onkyo. Example:

Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0

Whenever the transport was on any other file descriptor fd[1-9] sound will not play. Example

Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd1

So all I did today was (without restarting the bluealsa service)

# systemctl restart bluetooth.service
# bluetoothctl connect 00:09:B0:1C:CD:D4
Attempting to connect to 00:09:B0:1C:CD:D4
hci0 00:09:B0:1C:CD:D4 type BR/EDR connected eir_len 23
[CHG] Device 00:09:B0:1C:CD:D4 Connected: yes
[NEW] Endpoint /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep2 
[NEW] Endpoint /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1 
[NEW] Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0 

The file descriptor changed to fd0 and sound worked fine with

aplay -D bluealsa Track06.wav

Then I ran the commands

# bluetoothctl disconnect
# bluetoothctl connect 00:09:B0:1C:CD:D4
Attempting to connect to 00:09:B0:1C:CD:D4
hci0 00:09:B0:1C:CD:D4 type BR/EDR connected eir_len 23
[CHG] Device 00:09:B0:1C:CD:D4 Connected: yes
[NEW] Endpoint /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep2 
[NEW] Endpoint /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1 
[NEW] Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd1 
Connection successful
# aplay -D bluealsa Track06.wav

Sure enough no sound with bluealsa.

I repeated this test four times and had the same result. Sound will only play when fd0 is the file descriptor with bluealsa. Sound played fine with any file descriptor with gnome (pipewire).

I did an internet search didn't find anything related to this problem.

I apologize for not understanding the problem well enough to report the problem correctly. I tested bluealsa with a bluetooth speaker and sound played fine with any file descriptor.

Now to make this more complicated. I have noticed that gnome rarely goes from active to idle with no sound but it recovers and sound is played in gnome through pipewire. When this occurs in gnome a bluetooth sink is not created. I restarted bluetooth.service and the bluetooth sink was recreated once I reconnected to the onkyo. However, sound played on any file descriptor (fd[0-9). I have not been able to reproduce this problem in gnome like I have done in bluealsa. I will see if I can force this condition in gnome and capture logs. I hope my explanation is clear if not please let me know.

Logs showing the findings discussed above.

sound.log
nosound.log

[spamtree]

Since I can now duplicate the problem easily. I went back and obtained some better logs. Timestamps are clear.

Sound and no sound logs. The no sound logs were obtained after disconnecting and then reconnecting bluetooth and sounds logs were obtained after restart bluealsa.service and bluetooth.service.

The only major differences I could see are the following sections in the log files:

no_sound_bluealsa.service.log.

Oct 26 11:12:41 travel bluealsa[1731]: codec-sbc.c:264: SBC setup: 44100 Hz JointStereo allocation=SNR blocks=16 sub-bands=8 bit-pool=40 => 256331 bps
Oct 26 11:12:41 travel bluealsa[1731]: a2dp-sbc.c:225: PCM IO loop: START: a2dp_sbc_enc_thread: A2DP Source (SBC)
Oct 26 11:12:41 travel bluealsa[1731]: ba-transport-pcm.c:259: PCM resume: 15
Oct 26 11:12:46 travel bluealsa[1731]: bluez.c:1450: Signal: org.freedesktop.DBus.Properties.PropertiesChanged(): org.bluez.MediaTransport1: State
Oct 26 11:12:46 travel bluealsa[1731]: ba-transport.c:323: Closing BT socket duplicate [19]: 20
Oct 26 11:12:46 travel bluealsa[1731]: ba-transport.c:656: Closing A2DP transport: 19
Oct 26 11:12:46 travel bluealsa[1731]: ba-transport-pcm.c:153: Exiting IO thread [ba-a2dp-sbc]: A2DP Source (SBC)

sound_bluealsa.service.log

Oct 26 11:05:46 travel bluealsa[1731]: codec-sbc.c:264: SBC setup: 44100 Hz JointStereo allocation=SNR blocks=16 sub-bands=8 bit-pool=40 => 256331 bps
Oct 26 11:05:46 travel bluealsa[1731]: a2dp-sbc.c:225: PCM IO loop: START: a2dp_sbc_enc_thread: A2DP Source (SBC)
Oct 26 11:05:46 travel bluealsa[1731]: ba-transport-pcm.c:259: PCM resume: 15
Oct 26 11:06:08 travel bluealsa[1731]: ba-transport-pcm.c:275: PCM drain: 15
Oct 26 11:06:08 travel bluealsa[1731]: ba-transport.c:471: PCM clients check keep-alive: 10000 ms
Oct 26 11:06:09 travel bluealsa[1731]: ba-transport-pcm.c:295: PCM drained
Oct 26 11:06:09 travel bluealsa[1731]: ba-transport-pcm.c:303: PCM drop: 15
Oct 26 11:06:09 travel bluealsa[1731]: ba-transport-pcm.c:303: PCM drop: 15
Oct 26 11:06:09 travel bluealsa[1731]: io.c:201: PCM client closed connection: 15
Oct 26 11:06:09 travel bluealsa[1731]: ba-transport-pcm.c:238: Closing PCM: 15
Oct 26 11:06:09 travel bluealsa[1731]: ba-transport.c:471: PCM clients check keep-alive: 10000 ms
Oct 26 11:06:09 travel bluealsa[1731]: ba-transport.c:471: PCM clients check keep-alive: 10000 ms
Oct 26 11:06:09 travel bluealsa[1731]: ba-transport.c:471: PCM clients check keep-alive: 10000 ms                                                               
Oct 26 11:06:19 travel bluealsa[1731]: ba-transport.c:422: Stopping transport: No PCM clients                                                                   
Oct 26 11:06:19 travel bluealsa[1731]: ba-transport.c:323: Closing BT socket duplicate [19]: 20                                                                 
Oct 26 11:06:19 travel bluealsa[1731]: ba-transport.c:629: Releasing A2DP transport: 19                                                                         
Oct 26 11:06:19 travel bluealsa[1731]: bluez.c:1450: Signal: org.freedesktop.DBus.Properties.PropertiesChanged(): org.bluez.MediaTransport1: State
Oct 26 11:06:19 travel bluealsa[1731]: ba-transport.c:656: Closing A2DP transport: 19
Oct 26 11:06:19 travel bluealsa[1731]: ba-transport-pcm.c:153: Exiting IO thread [ba-a2dp-sbc]: A2DP Source (SBC)

no_sound_bluetooth.service.log

Oct 26 11:12:41 travel bluetoothd[1730]: profiles/audio/transport.c:transport_set_state() State changed /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd1: TRANSPORT_STATE_REQUESTING ->TRANSPORT_STATE_ACTIVE
Oct 26 11:12:41 travel bluetoothd[1730]: profiles/audio/a2dp.c:setup_unref() 0x5559a0c21ca0: ref=0
Oct 26 11:12:41 travel bluetoothd[1730]: profiles/audio/a2dp.c:setup_free() 0x5559a0c21ca0
Oct 26 11:12:41 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_unref() 0x5559a0c45050: ref=2
Oct 26 11:12:41 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed: OPEN -> STREAMING
Oct 26 11:12:41 travel bluetoothd[1730]: profiles/audio/sink.c:sink_set_state() State changed /org/blue/hci0/dev_00_09_B0_1C_CD_D4: SINK_STATE_CONNECTED -> SINK_STATE_PLAYING
Oct 26 11:12:41 travel bluetoothd[1730]: profiles/audio/transport.c:transport_update_playing() /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd1 State=TRANSPORT_STATE_ACTIVE Playing=1
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/avdtp.c:session_cb()
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_parse_cmd() Received SUSPEND_CMD
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/a2dp.c:suspend_ind() Source 0x5559a0bf6bf0: Suspend_Ind
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed: STREAMING -> OPEN
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/sink.c:sink_set_state() State changed /org/bluez/hci0/dev_00_09_B0_1C_CD_D4: SINK_STATE_PLAYING -> SINK_STATE_CONNECTED
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/transport.c:transport_update_playing() /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd1 State=TRANSPORT_STATE_ACTIVE Playing=0
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/transport.c:media_transport_remove_owner() Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd1 Owner :1.46
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/transport.c:media_owner_free() Owner :1.46
Oct 26 11:12:46 travel bluetoothd[1730]: profiles/audio/transport.c:transport_set_state() State changed /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd1: TRANSPORT_STATE_ACTIVE -> TRANSPORT_STATE_IDLE

sound_bluetooth.service.log

Oct 26 11:05:46 travel bluetoothd[1730]: profiles/audio/transport.c:transport_set_state() State changed /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0: TRANSPORT_STATE_REQUESTING -> TRANSPORT_STATE_ACTIVE
Oct 26 11:05:46 travel bluetoothd[1730]: profiles/audio/a2dp.c:setup_unref() 0x5559a0bf4dc0: ref=0
Oct 26 11:05:46 travel bluetoothd[1730]: profiles/audio/a2dp.c:setup_free() 0x5559a0bf4dc0
Oct 26 11:05:46 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_unref() 0x5559a0c2a550: ref=2
Oct 26 11:05:46 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed: OPEN -> STREAMING
Oct 26 11:05:46 travel bluetoothd[1730]: profiles/audio/sink.c:sink_set_state() State changed /org/bluez/hci0/dev_00_09_B0_1C_CD_D4: SINK_STATE_CONNECTED -> SINK_STATE_PLAYING
Oct 26 11:05:46 travel bluetoothd[1730]: profiles/audio/transport.c:transport_update_playing() /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0 State=TRANSPORT_STATE_ACTIVE Playing=1
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/transport.c:transport_set_state() State changed /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0: TRANSPORT_STATE_ACTIVE -> TRANSPORT_STATE_SUSPENDING
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_ref() 0x5559a0c2a550: ref=3
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/a2dp.c:setup_ref() 0x5559a0bf4dc0: ref=1
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/transport.c:media_request_create() Request created: method=Release id=5
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/transport.c:media_owner_add() Owner :1.46 Request Release
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/avdtp.c:session_cb()
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_parse_resp() SUSPEND request succeeded
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed: STREAMING -> OPEN
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/sink.c:sink_set_state() State changed /org/bluez/hci0/dev_00_09_B0_1C_CD_D4: SINK_STATE_PLAYING -> SINK_STATE_CONNECTED
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/transport.c:transport_update_playing() /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0 State=TRANSPORT_STATE_SUSPENDING Playing=0
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/a2dp.c:suspend_cfm() Source 0x5559a0bf6bf0: Suspend_Cfm
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/transport.c:media_request_reply() Request Release Reply Success
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/transport.c:media_owner_remove() Owner :1.46 Request Release
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/a2dp.c:a2dp_sep_unlock() SEP 0x5559a0bf6bf0 unlocked
Oct 26 11:06:19 travel bluetoothd[1730]: profiles/audio/transport.c:transport_set_state() State changed /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep1/fd0: TRANSPORT_STATE_SUSPENDING -> TRANSPORT_STATE_IDLE

In no_sound_bluealsa.service.log once play is started in 5 seconds the state changes from active to idle. In the sound_bluealsa.service.log once play is started the audio is played and state does not change to idle until the audio is completed. Similar events occur in the bluetooth.service.logs

Full logs with timestamps below.

no_sound_bluealsa.service.log
sound_bluealsa.service.log
no_sound_bluetooth.service.log
sound_bluetooth.service.log

[arkq]

The file descriptor had to be fd0 for sound to play with bluealsa to the onkyo.

Hmm... interesting notice. There is something in BlueALSA that is not in PulseAudio nor in PipeWire. BlueALSA registers more than one SEP for a single A2DP codec (in order to allow more then one device to be connected via the same codec). However, that might trip onkyo.... Here is a patch which will "turn off" that feature. Please, try to use is. I'm not sure whether it will work or not, but applying it will bring BlueALSA closer to PipeWire implementation (which works).

diff --git a/src/bluez.c b/src/bluez.c
index 94f107c..0782abf 100644
--- a/src/bluez.c
+++ b/src/bluez.c
@@ -740,7 +740,7 @@ static void bluez_export_a2dp(
                if (dbus_obj->connected)
                        connected++;

-               continue;
+               break;

 fail:
                if (err != NULL) {

[spamtree]

Will do. Thanks

[spamtree]

That patch did not work. Audio output only when file descriptor is fd0.

Followup: I know this has nothing to due with the bug report but wanted to clear up this issue in case anyone else reads this thread. The Gnome problem with no audio after boot is a bug somewhere. Pipewire audio sink is not created unless bluetooth.service is started after the user logon. Restarting bluetooth.service after logon, bluetooth audio works perfectly. This happened with a bluetooth speaker and the onkyo receiver. This is an easy work around. This does not happen on my other laptop. Probably has something to do with this error on boot.

systemd[1]: Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).

Thanks again.

[borine]

The bluez transport object path uses a simple global counter to number the fdN component. So the first A2DP transport created after the bluetooth daemon has started is fd0. When you disconnect the onkyo that transport is removed, and when you reconnect a new one is created, fd1, etc. That is normal. So I think a better way of describing the symptoms here is that only the first connection attempt to the onkyo after starting bluetooth produces a working transport, all subsequent attempts result in the stream being suspended 5 seconds after starting. I would be interested to know what happens if the first connection after starting bluetooth is to some other device, then disconnect that and now connect to the Onkyo. The Onkyo transport will be fd1, but does it produce a working stream?

On the same theme, what happens if the first connection (fd0) is to the Onkyo, then the second (fd1) to some other device, then the third (fd2) to the Onkyo again; does the final Onkyo connection produce sound?

[borine]

systemd[1]: Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).

That indicates that systemd is trying to start the bluetooth service when then are no bluetooth adapters available. Either the USB adapter was not plugged in at boot, or else the kernel has not finished probing the USB bus before systemd tries to start bluetooth.

[spamtree]

The bluez transport object path uses a simple global counter to number the fdN component. So the first A2DP transport created after the bluetooth daemon has started is fd0. When you disconnect the onkyo that transport is removed, and when you reconnect a new one is created, fd1, etc. That is normal. So I think a better way of describing the symptoms here is that only the first connection attempt to the onkyo after starting bluetooth produces a working transport, all subsequent attempts result in the stream being suspended 5 seconds after starting. I would be interested to know what happens if the first connection after starting bluetooth is to some other device, then disconnect that and now connect to the Onkyo. The Onkyo transport will be fd1, but does it produce a working stream?

On the same theme, what happens if the first connection (fd0) is to the Onkyo, then the second (fd1) to some other device, then the third (fd2) to the Onkyo again; does the final Onkyo connection produce sound?

I repeated this several times with a bluetooth speaker that works great with bluealsa or anything else. Still no audio on the onkyo receiver if the file descriptor is not fd0. I started the onkyo first on fd0 and then started the bluetooth speaker first on fd0. Repeated several times and once the file descriptor was not fd0 no sound on the onkyo. The bluetooth speaker worked everytime on any file descriptor number.

onkyo fd0 -> audio, bluetooth speaker fd1 -> audio, onkyo fd2 -> no audio,  bluetooth speaker fd3 -> audio

bluetooth speaker fd0 -> audio, onkyo fd1 -> no audio,  bluetooth speaker fd2 -> audio, onkyo fd3 -> no audio

So does not matter if bluetooth speaker starts the stream first, the onkyo does not play if the file descriptor is not fd0. bluetooth goes from active to inactive in five seconds each time with the onkyo if the file descriptor is not fd0.

[arkq]

That patch did not work.

OK, so there is nothing else than to collect BT traffic from working setup (with gnome) and with not working setup (bluealsa). Please use sudo tcpdump -i bluetooth0 -w /tmp/bluetooth.tcpdump on both setups. Please run the tcpdump command BEFORE connecting bluetooth device (make sure that before starting tcpdump BT device is disconnected), otherwise it will be hard to read these logs. Please start short (~5 seconds) audio playback two times (so in case of bluealsa we will get fd0 and fd1 case recorded). You can keep the continue -> break patch from the previous comment (this will simplify the BT traffic).

I repeated this several times with a bluetooth speaker that works great with bluealsa or anything else. Still no audio on the onkyo receiver if the file descriptor is not fd0. I started the onkyo first on fd0 and then started the bluetooth speaker first on fd0.

And one more thing to check. This fd0 -> fd1 transition is not unique to BlueALSA, it should be the same with PipeWire as well. However, it would be nice to verify that with sudo dbus-monitor --system "sender=org.bluez" "destination=org.bluez" on gnome by starting playback twice.

[borine]

on gnome by starting playback twice.

Just to clarify, you need to disconnect then re-connect the onkyo between the first and second playbacks in order to get a new transport object each time.

Also (apologies for throwing in this request at the same time as @arkq 's above)
Previously, using "aplay -D onkyo" appeared to fix the problem, it would be interesting to know how that affects the transport D-Bus object path. Incidentally, if you just need to see the object paths, there is no need to collect logs, you can use D-Bus. A nice tool for this is busctl which comes with systemd:

user@host:~$ busctl tree org.bluez
└─/org
  └─/org/bluez
    └─/org/bluez/hci0
      ├─/org/bluez/hci0/dev_00_00_00_65_70_FD
      ├─/org/bluez/hci0/dev_0C_CF_89_61_53_68
      ├─/org/bluez/hci0/dev_5C_F3_70_9B_FB_1A
      │ ├─/org/bluez/hci0/dev_5C_F3_70_9B_FB_1A/player0
      │ ├─/org/bluez/hci0/dev_5C_F3_70_9B_FB_1A/sep1
      │ ├─/org/bluez/hci0/dev_5C_F3_70_9B_FB_1A/sep2
      │ ├─/org/bluez/hci0/dev_5C_F3_70_9B_FB_1A/sep3
      │ └─/org/bluez/hci0/dev_5C_F3_70_9B_FB_1A/sep4
      │   └─/org/bluez/hci0/dev_5C_F3_70_9B_FB_1A/sep4/fd3
      ├─/org/bluez/hci0/dev_80_56_F2_C8_AF_60
      ├─/org/bluez/hci0/dev_B8_27_EB_2B_8D_C3
      ├─/org/bluez/hci0/dev_B8_27_EB_B5_D7_9F
      ├─/org/bluez/hci0/dev_B8_8D_12_19_4B_9F
      └─/org/bluez/hci0/dev_C4_67_B5_37_26_FC

[spamtree]

Interesting. I think I understand will do. One question

Please run the tcpdump command BEFORE connecting bluetooth device (make sure that before starting tcpdump BT device is disconnected), otherwise it will be hard to read these logs.

Bluetooth device is the bluetooth speaker, onkyo receiver or both (onkyo and bluetooth speaker)? I was going to do both is that okay?

aplay -D onkyo track.wav

Does not work once file descriptor is not on fd0. I think when it worked I had probably had restarted bluetooth.service and didn't realize that the file descriptor could be a problem.

Should I obtain the D-Bus object path before or after running "aplay"?

Thanks

[arkq]

Bluetooth device is the bluetooth speaker, onkyo receiver or both

Yyyy... now I think that I do not quite understand your setup :D When I'm talking about Bluetooth device I mean a device which is connected (via Bluetooth) to the host with PipeWire/BlueALSA on board. So, all I care about is this link (if my understanding of your setup is right):

PipeWire/BlueALSA A2DP source --->  Onkyo Bluetooth A2DP sink 

Or maybe your setup is somehow different? Because I thought that Onkyo IS a Bluetooth-enabled device, i.e. Blueooth speaker (or at least a component which receives A2DP Bluetooth audio from BlueALSA/PipeWire).

[borine]

Should I obtain the D-Bus object path before or after running "aplay"?

I should have been clearer: find the object path (.../sep1/fd0) as soon as the onkyo is connected, then again after

aplay -D bluealsa:CODEC=sbc:21150228 Track06.wav

but before disconnecting the onko. I would expect the path to have changed to ..../sep1/fd1. If it has changed to fd1, does the same aplay command still work (without first disconnecting)? However, if you've already checked that it does not work then I guess this test is redundant anyway.

[borine]

A random thought that just occurred to me. I notice from the bluetoothctl info output in the first post here that the Onkyo is "Trusted" by Bluez. So this raises the question, when the bluetooth service is first started, does the Onkyo auto-connect, or do you have to do bluetoothctl connect to connect it? If it does autoconnect, then maybe that is the difference between the first connection (transport fd0) and subsequent connections?

[spamtree]

Bluetooth device is the bluetooth speaker, onkyo receiver or both

Yyyy... now I think that I do not quite understand your setup :D When I'm talking about Bluetooth device I mean a device which is connected (via Bluetooth) to the host with PipeWire/BlueALSA on board. So, all I care about is this link (if my understanding of your setup is right):

PipeWire/BlueALSA A2DP source --->  Onkyo Bluetooth A2DP sink 

Or maybe your setup is somehow different? Because I thought that Onkyo IS a Bluetooth-enabled device, i.e. Blueooth speaker (or at least a component which receives A2DP Bluetooth audio from BlueALSA/PipeWire).

That is what I thought you meant and will do. I just wanted to make sure. That is my setup.

[spamtree]

Should I obtain the D-Bus object path before or after running "aplay"?

I should have been clearer: find the object path (.../sep1/fd0) as soon as the onkyo is connected, then again after

aplay -D bluealsa:CODEC=sbc:21150228 Track06.wav

but before disconnecting the onko. I would expect the path to have changed to ..../sep1/fd1. If it has changed to fd1, does the same aplay command still work (without first disconnecting)? However, if you've already checked that it does not work then I guess this test is redundant anyway.

I see what you mean. The object path will be in the bluez logs.

Once the object path changes from "fd0" the following command does NOT produce audio.

aplay -D bluealsa:CODEC=sbc:21150228 Track06.wav

I turned autoconnect off on the onkyo.

Thanks again for the clarification @arkq and @borine!

[spamtree]

Here are the logs. If there is a problem please let me know. I will be happy to reproduce or create new logs. The bluez logs were started at the same time the tcpdump logs were started. If the naming convention is not clear please let me know.

tcpdump-logs.zip

[borine]

@spamtree to see if the RTP sequence and timestamp difference matters, try this patch:

diff --git a/src/rtp.c b/src/rtp.c
index 63d002c..40c8890 100644
--- a/src/rtp.c
+++ b/src/rtp.c
@@ -85,12 +85,12 @@ void rtp_state_init(
 
 	rtp->synced = false;
 
-	rtp->seq_number = rand();
+	rtp->seq_number = 0;
 
 	rtp->ts_pcm_frames = 0;
 	rtp->ts_pcm_samplerate = pcm_samplerate;
 	rtp->ts_rtp_clockrate = rtp_clockrate;
-	rtp->ts_offset = rand();
+	rtp->ts_offset = 0;
 
 }

[spamtree]

Didn't work on fd1 but worked fine on fd0 and patch was applied - checked source code.

Logs:

rtp-0.zip

[borine]

So its not RTP that is the problem. Thanks for testing.

[spamtree]

I went back and reviewed the logs. I remember what @borine asked do you need hit play to start playing? This may be a long shot but check this out and it is present in the previous logs that I sent with bluetooth.service.

I found this in the logs in fd0.log that was not in fd1.log or in the gnome (pipewire) logs.

Oct 29 14:16:13 travel bluetoothd[2268]: profiles/audio/avctp.c:handle_panel_passthrough() AV/C: PLAY pressed
Oct 29 14:16:13 travel bluetoothd[2268]: profiles/audio/avctp.c:handle_panel_passthrough() AV/C: PLAY released

These are bluealsa.service and bluetooth.service logs combined. Reviewed the old logs that I have done and found the same finding in the bluetooth.service logs.

grep -l 'PLAY pressed' *.log

Is only in bluetooth.service log files with fd0 and onkyo. This is not present in fd1 and onkyo and no sound.

In the fd1 logs where "PLAY pressed" is not present and switches back to idle mode for the onkyo. This string "PLAY pressed" is not present in gnome with onkyo or bluetooth speaker or with bluealsa and bluetooth speaker.

Not sure what this means but wanted to report this finding.
bluealsa_btspeaker_fd1.log
bluealsa_btspeaker_fd0.log
bluealsa_onkyo_fd1.log
bluealsa_onkyo_fd0.log
gnome_onkyo_fd1.log
gnome_onkyo_fd0.log

[borine]

Is only in bluetooth.service log files with fd0 and onky

It is present in all the fd0 logs for the onkyo. It is an AVRCP command sent from the onkyo to the linux host, and is simply to inform the source that the user has pressed the "play" button (on the onkyo or its remote). I suspect that this is actually sent when you select "bluetooth" as the source on the onkyo. If you select some other source, I expect it will send a Stop or Pause pressed/released sequence.

[spamtree]

Will test that hypothesis. I have never pressed the a play button on the onkyo and it is always on bluetooth since I have been testing. All I do is disconnect and reconnect with a different computer through bluetooth control. Sometimes I will turn the computer bluetooth controller off and on. I never touch the onkyo unless I need pair the device which I have not done lately.

[spamtree]

You folks have been wonderful for looking into this problem.

@borine you were 100% correct the key press has nothing to do with the problem. Anyway thanks for the explanation. However, trying to figure out how to send bluealsa commands, I ran across this interesting command "bluealsa-cli". While playing around with bluealsa-cli I was able to get audio working on any file descriptor.

Before reporting this finding, I decided to start with a clean bluealsa setup and recompiled the bluealsa master without the patches. Also went back to the default systemd service command.

/usr/bin/bluealsa -S -p a2dp-source -p a2dp-sink

Changing the codec with bluealsa-cli when no sound was played restored audio playback (sound returned) with any file descriptor. Didn't matter what codec was used SBC or AAC. Audio plays with SBC or AAC after codec change. Changed the codec with the following command and creates a new file descriptor (see bluetoothctl.log).

bluealsa-cli codec /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink AAC

Then I turned on onkyo autoconnect and made sure audio was not working. Then turned off and on the onkyo. The onkyo reconnected with the pc and audio played on any file descriptor.

I repeated these tests several time (see logs). The tests are reproducible.

Of course I have no idea what is going on but at least I am at a point I understand how to reproduce the problem and I can work around the problem. For some reason using disconnect and connect (in that sequence) with bluetoothctl+bluealsa and the file descriptor is not fd0 there is no audio (does not matter what codec is used). However, if I use onkyo autoconnect function to reconnect then audio works on any file descriptor or audio works when changing the codec with "bluealsa-cli".

Lastly everything works with gnome doing the same tests (used pulseaudio volume control" to change codec and used bluetoothctl sequence disconnect and then connect). Today it was interesting because the last time I checked the codec in gnome the "AAC" option was missing but after changing bluealsa to use "AAC", the "AAC option is now present in gnome and works fine. Changing the codec in gnome also changes the file descriptor. Onkyo autoconnect works fine in gnome.

If there is an explanation for this behavior, I would love to hear it.

Logs attached with comments in bluetoothctl.log. To move around quickly in the bluetooth.service-bluealsa.service.log and the bluetoothctl.log, search on the file descriptor.

bluetoothctl.log
bluetooth.service-bluealsa.service.log

[borine]

Thanks for the new information, I'll work through it in a few days. Previously I thought gnome and bluealsa were on different machines, with different bluetooth adapters. Is that correct? I ask because the appearance of AAC in gnome after selecting it in bluealsa is somewhat surprising if they are fifferent hosts.

[spamtree]

Absolutely no rush at all I really appreciate you folks looking into this matter. I maybe away from the onkyo for a while but I will get back to you when I return. You are correct there are on completely different computers. I can run tests quicker that way. It could be because of a recent update to the system. I thought it was strange also.

Anyway to make sure that was not a hardware problem I installed bluealsa on the gnome computer and the same result as previously reported in my last message.

[borine]

I'm still struggling to find any convincing difference in the bluetooth messaging within the bluealsa sessions and the gnome sessions, except that with bluealsa the onkyo suspends the second transport session ("fd1") after 5 seconds only with bluealsa.

So we will now have to resort to attempting to test some differences which should not affect the success of the transport, but (perhaps because of bugs in the onkyo firmware) maybe they do.

The first obvious difference is that in the gnome sessions the transport is acquired within 25ms of the onkyo connecting, and 5 seconds of audio are played (I am assuming it is silence that is being sent). Then the transport is released, and then acquired again after 3 seconds. I guess this is your test file now being played.

Using bluealsa we cannot easily reproduce the immediate acquisition as performed by gnome, but we can at least send a preamble of 5 seconds silence before out test file, just to see if that is the key difference between the bluealsa and gnome sessions.

Please can you try the following test sequence:
[EDIT - please make sure that bluealsa is not using the --keep-alive option, because that would prevent the transport from being released and then re-acquired between the 2 aplay runs ]
`

# completely reset the bluetooth daemon state
sudo systemctl restart bluetooth

# connect the onkyo
bluetoothctl connect 00:09:B0:1C:CD:D4

# play 5 seconds of silence
aplay -D bluealsa -t raw -f s16_le -r 44100 -c 2 -d 5 /dev/zero

# play the test file
aplay -D bluealsa Track06.wav

# wait for playback to finish, then disconnect the onkyo
bluetoothctl disconnect 00:09:B0:1C:CD:D4

# reconnect the onkyp
bluetoothctl connect 00:09:B0:1C:CD:D4

# play 5 seconds of silence
aplay -D bluealsa -t raw -f s16_le -r 44100 -c 2 -d 5 /dev/zero

# play the test file
aplay -D bluealsa Track06.wav

Does the test file now play correctly in this second connection?

[EDIT 2] If aplay terminates with the error "Drain timed out: Possible Bluetooth transport failure", then please can you try again after applying the patch from #670

[borine]

Apologies for sending another test so soon, I just want to record these thoughts as they occur to me.

The second difference in the application layer is that bluealsa connects the "Delay Reporting Service" in the AVDTP SetConfiguration command, whereas (rather surprisingly) gnome does not. To test if this is the key difference for the failed second transport, it is necessary to patch the bluealsa master branch sources.

diff --git a/src/bluez.c b/src/bluez.c
index 94f107c..ca62087 100644
--- a/src/bluez.c
+++ b/src/bluez.c
@@ -643,7 +643,7 @@ static GVariant *bluez_media_endpoint_iface_get_property(
 		return g_variant_new_fixed_array(G_VARIANT_TYPE_BYTE,
 				&codec->capabilities, codec->capabilities_size, sizeof(uint8_t));
 	if (strcmp(property, "DelayReporting") == 0)
-		return g_variant_new_boolean(TRUE);
+		return g_variant_new_boolean(FALSE);
 
 	g_assert_not_reached();
 	return NULL;

With that patch in place, try the sequence:

sudo systemctl restart bluetooth
sleep 2
bluetoothctl connect 00:09:B0:1C:CD:D4
aplay -D bluealsa Track06.wav
bluetoothctl disconnect 00:09:B0:1C:CD:D4
bluetoothctl connect 00:09:B0:1C:CD:D4
aplay -D bluealsa Track06.wav

Does the second aplay now work correctly?

[spamtree]

I have been out for work. As soon as I get back will test this patch and recommended commands. Please don't close this thread.

Thanks!

[spamtree]

@borine

I hope everyone is doing well.

Compiled bluealsa with the lastest git and only your patch. Ran the command exactly as recommended. No change at all from previous behavior. After disconnect there is no sound. The State of the device goes from active to idle immediately after starting playback. Example below.

[CHG] Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep2/fd1 State: active
[CHG] Transport /org/bluez/hci0/dev_00_09_B0_1C_CD_D4/sep2/fd1 State: idle

Switching the codec restored sound as before.

bluealsa-cli codec /org/bluealsa/hci0/dev_00_09_B0_1C_CD_D4/a2dpsrc/sink SBC

In summary the second aplay did not produce any sound.

Do you want some fresh logs?

[borine]

I'm afraid I'm out of ideas now. I just cannot see why the onkyo is stopping the stream. All of the A2DP and AVDTP control messaging looks correct. If I get any new thoughts I'll post them here.