Sending RING Indicate to Connected Headsets

[bcroxall]

Arkq,

We're using bluealsa to send audio to a connected headset with gstreamer but now need to be able to send a ring indicate from our application. I cannot find this functionality in your code but I do see the ability to send a custom AT command. As you are probably aware, to do this we need to send /r/nRING/r/n to the rfcomm file descriptor for each connected headset.

Is this something you plan to implement in bluealsa? If so, do you have an expected timeline to do so? If not, will you provide some guidelines on how to send a ring indicate command to any connected headsets from a separate application via bluealsa?

Thanks for your help.

[arkq]

Hi,

We [...] need to be able to send a ring indicate from our application. Is this something you plan to implement in bluealsa?

Yes, I do have.

If so, do you have an expected timeline to do so?

I'm afraid it is rather a distant future. Currently, I want to close/fix issues related to audio transport within HFP/HSP profiles.

If not, will you provide some guidelines on how to send a ring indicate command to any connected headsets from a separate application via bluealsa?

My general idea is to expose RFCOMM via bluealsa itself as a "proxy" socket. By doing so, bluealsa will be able to filter audio related commands and forward unrelated ones. In this way, it will be possible to establish Service Level Connection, and allow other application to communicate with BT headset without the requirement of implementing RFCOMM "stack". But it is just an idea. I don't have any prof-of-concept implementation.

[bcroxall]

Hey,

Thanks for the quick response. We'd really like to work through this. It's a requirement for our product.

I have a few questions.

By "proxy" socket, I presume you mean that an application would get a file descriptor for a device from bluealsa and the application would then "write" to that file descriptor with an api call to bluealsa, which would write to the actual file descriptor. Is that kind of what you are thinking? I'm wondering if it might look very similar to how bluealsa now registers a profile with bluez and gets a new connection callback with a file descriptor when a device is added. Could an application register for new connections of specific profiles with bluealsa and get callbacks with proxy file descriptors when those devices are added? We couldn't write directly with those descriptors but would make a call to bluealsa to write for us?

How would the application communicate with bluealsa? Would there be a network socket or would the application and bluealsa communicate over dbus or some other way?

Again, thanks for your help.

[arkq]

By "proxy" socket, I presume you mean that an application would get a file descriptor for a device from bluealsa and the application would then "write" to that file descriptor with an api call to bluealsa, which would write to the actual file descriptor. Is that kind of what you are thinking?

Yes, generally, that is my idea. I don't know though, if it is a right way to implement such a feature. A lot of my ideas were shattered when they have faced reality :) If you've got some thoughts, I'd be glad to hear them.

How would the application communicate with bluealsa? Would there be a network socket or would the application and bluealsa communicate over dbus or some other way?

Currently, there is a piece of code in the src/shared in files prefixed with ctl-, which is responsible for communication with bluealsa via controller socket. I think, that obtaining RFCOMM shall be implemented in a similar way, the PCM FIFO is obtained (with a small difference, though). When you've asked if this socket should be exposed in a similar way, the transport socket is passed from BlueZ to BlueALSA, it has struck me, that PCM FIFO can also be exported in the same fashion - it will simplify communication a little bit. I'm talking about passing file descriptor via socket.

[bcroxall]

Arkq,

Thanks again for your response. I'm wondering if you would be willing to help us by getting ring indicate working quickly. Is there a way I could contact you off-line to discuss your availability and options?

Thanks.

[arkq]

Hi,

I'm wondering if you would be willing to help us by getting ring indicate working quickly.

:) I'm afraid it is not possible. I'm rather busy right now (that's why the pace with this project has slowed down a little bit). Furthermore, I do not like to make things "quickly" in the pro publico bono open source project - simply it's a waste of time in the long term perspective. Like I said before, I do have plans for RFCOMM communication, but not right now. There are more important architectural changes to be made (e.g. #48 ), and RFCOMM will only blur the image and add another thing to maintain during changes. Of course if you provide some PR with RFCOMM forwarding, I will review it and if it is solid enough I will merge it (maybe not right away, but eventually). Sorry.

Is there a way I could contact you off-line.

Yes, it is: #bluealsa @freenode. If I'm not there, you need to email me (email is available in the git tree), because I'm not logged all the time :). I'm living in the UTC+1 time zone, so please keep that in mind :)

PS.
The changes I was talking about in my previous post (file descriptor sharing simplification) are already in the master.

[arkq]

I'm closing this issue, since it has been resolved in the #102.