Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple sink transports active simultaneously #70

Closed
mill1000 opened this issue Dec 9, 2017 · 13 comments

Comments

Projects
None yet
4 participants
@mill1000
Copy link

commented Dec 9, 2017

Not sure if this counts as a bug or a feature....

I've notice that multiple sink transport can be active at one time allowing multiple devices to play audio. This is problematic when trying to use blueALSA in a Bluetooth speaker configuration as you would only want one device playing audio at a time.

Do you feel this mutual exclusion should occur within blueALSA or at a higher level? Perhaps within the Bluetooth connection manager?

@Arkq

This comment has been minimized.

Copy link
Owner

commented Dec 9, 2017

Hi,

I've actually spent some time to make this "feature" possible :). However, I'm glad you've created this issue. User feedback is always a great value.

In short, I've tried to make audio connectivity as flexible as possible, so later someone (or I) might use it in a whatever configuration one likes. If you are using bluealsa-aplay for playing audio from Bluetooth sinks, I think that it is reasonable to add option to indeed disable playing multiple audio at once (it has crossed my mind before, that it would be nice to play only one audio in order to mimic "standard" Bluetooth speaker). However, it might not be very the same as with a standard Bluetooth speaker. Standard Bluetooth speaker blocks playing audio from second (third, ... etc.) device, so it is visible (e.g. on smartphone) (if I'm not mistaken) that the audio is not playing. Recreating something similar would require things that I'm not sure I'll make - it will introduce unnecessary spaghetti code. So, the simplest version of this "counter-feature" will be as follows:

  1. first person connects BT device 1 and starts playing audio which is audible
  2. second person connects another BT device and starts playing audio; smartphone music player indicates that the audio is playing, however it is not audible
  3. first person disconnects or stops playing, then immediately audio from the second device is audible
  4. first person starts playback and audio is not audible until step 3 occurs for the second person

What do you think?

If you are not using bluealsa-aplay for creating Bluetooth audio, this "feature" is beyond my control. And it should be implemented in the application you are using - mixing/multiplexing audio from two microphones (Bluetooth sinks).

@mill1000

This comment has been minimized.

Copy link
Author

commented Dec 11, 2017

I think making the software as flexible as possible is a good way to develop. So glad to hear that.

The counter-feature is not ideal for my application because it will not be intuitive enough for the average user of a "standard" Bluetooth speaker. I believe I can mimic the behavior I want within the Bluetooth agent and leave bluez-alsa to do what it does best.

Meanwhile I'll be reading up on the AVRCP protocol.

@Arkq

This comment has been minimized.

Copy link
Owner

commented Dec 11, 2017

I've made a little bit of testing, and it seems that even though I would made required changes (not reading data from the bluez socket), the desired effect wouldn't be achieved - my smartphone still indicates that the audio is playing.

Since I don't have BT speaker, in order to further investigate this feature I would need some assist. I need btsnoop logs from two (Android-based) smartphones (iphone might be good as well, however I don't know how to obtain BT logs from iOS) sending data to the real BT speaker in the following fashion:

  1. Enable HCI logging on both devices.
  2. Connect smartphone 1 to the speaker.
  3. Connect smartphone 2 to the speaker.
  4. Start playing audio from smartphone 1.
  5. Start playing audio from smartphone 2 (and see if the playback indicator shows progress, if progress is shown, nothing to do here.... if progress indicates that the audio is not playing, we're good).
  6. Stop audio on smartphone 1.
  7. If audio on smartphone 2 hasn't started automatically, start it.
  8. Stop everything and get btsnoop_hci.log files from both devices.
@mill1000

This comment has been minimized.

Copy link
Author

commented Dec 12, 2017

So interesting enough, the first two devices I had readily available enforce their exclusivity through the Bluetooth connection itself. So that's a bust. In a few days I should have access to some other devices and I can try to get some usable logs.

@Arkq

This comment has been minimized.

Copy link
Owner

commented Dec 12, 2017

@infirit

This comment has been minimized.

Copy link

commented Dec 12, 2017

I need btsnoop logs from two (Android-based) smartphones (iphone might be good as well, however I don't know how to obtain BT logs from iOS) sending data to the real BT speaker in the following fashion:

I have a xiaomi mi speaker. Will upload the logs somewhere for my lineage 7.1 phone.

edit: It does not allow multiple connections so ignore this comment :-)

@graham8

This comment has been minimized.

Copy link

commented Dec 12, 2017

Nvidia Tegra Note tablet vs Samsung Galaxy S4 playing to JBL Flip 3. Both can connect at the same time. Playing music from Samsung blocks Tegra. When playing music from Tegra, Samsung butts in and plays it's own music. Will try to get you logs later.

@graham8

This comment has been minimized.

Copy link

commented Dec 12, 2017

Some logs for you: https://www.dropbox.com/sh/ow68oflne3n198v/AADDpVcenHwSu554O4o8Sd-oa?dl=0
In test 1, I started music on Samsung, then on Tegra Note. This time the Tegra managed to grab the connection but only after a while. The speaker became disconnected from both for a bit then re-connected to the Tegra. When Tegra took over, playback on Samsung was paused.
In test 2, I did the same but after Tegra was playing through the speaker re-started music on Samsung, which then took over the connection. Repeated this a few times.
Note that in the earlier test, Samsung was running Total Commander to play music, Tegra Kodi. For these logs, both running Total Commander.
Hope this helps.

@Arkq

This comment has been minimized.

Copy link
Owner

commented Dec 12, 2017

Thanks, for logs. I'll try to analyse them later. However, it seems that logs samsung1 and tegra2 are somehow "corrupted" - it seems that connection phase is missing, so Wireshark is not able to properly decode BT frames. When you open these logs in Wireshark, you will see red-marked lines, which indicates that something is missing (see attached picture).

screenshot

Also, did you paused and started playback on Tegra during test 1? Because in logs I can see command suspend sent from Tegra to speaker (at frame 12150) and 5s later (at frame 12163) command start, however you didn't mention that in the comment.

@graham8

This comment has been minimized.

Copy link

commented Dec 12, 2017

I started the sniff after connecting both to keep the file sizes down. I can re-run but why would samsung 2 and tegra 1 not have the same issue?

I did not pause Tegra in test 1. It was as if there was a tug of war between the two source devices. As I said both connections dropped for a while, so I would guess the start was issued by the app whan the connection was re-established.

I haven't looked at these in wireshark - I wouldn't really now what I was looking at.

@graham8

This comment has been minimized.

Copy link

commented Dec 12, 2017

OK. Two new logs added. This time I started logging before connecting each device, but there is no attempt to coordinate the start times of the logs. The behaviour was more like the very first test I reported. Tegra did not manage to grab the connection - I had to pause Samsung then re-start music on Tegra to get it to play. Then I re-started music on Samsung and it grabbed the connection back straight away. I couldn't immediately see any red lines in these logs so hope they help.

@Arkq Arkq closed this in d76191e Dec 17, 2017

@Arkq

This comment has been minimized.

Copy link
Owner

commented Dec 17, 2017

I've just pushed changes which will allow to block second, third, etc. device from playing. I think, that I've achieved desirable effect, however the outcome highly depends on the connected device. Blocking playback is easy. The tricky part is letting know connected BT device, that the audio will not be played. If device supports media player interface, I'm sending AVRCP pause command to the device.

I'm sure, that there is a more direct way to notify device, that the audio is not playing, however I'm not able to figure it out.... Also, I've checked connecting two devices to my Jabra MOVE headset, and to my surprise, only one audio can be heard, however both players indicate that the audio is playing. So, even commercially available device does it the easier way.

Please, test it and let me know if it works (I've tested it with two Android-based smartphones).

@mill1000

This comment has been minimized.

Copy link
Author

commented Dec 17, 2017

Very cool. I'll give it a test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.