avrcp and dbus
Hi
I have my test app ("avrecv") accepting connections and ack'ing passthrough commands. Most or all headsets are going to be sending passthrough only, but we will nak other commands when I figure out how the nak looks.
If you have avrecv running when you start sending audio to the set, the headset will turn around and make the avrcp connection. I don't know how you use the play button to *initiate* the player however... :(
I would like to make this app a multithreaded daemon and hook it up to dbus for both receiving events from headsets and relaying things back to the headset (eg volume changes). I will run one thread per connection and select() between data from the headset and dbus commands for the same l2cap connection...
Does the dbus approach sound reasonable? Any tips for where to start with dbus? (I've never written for it)
Brad
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Brad,
Quoted 8 lines
I have my test app ("avrecv") accepting connections and ack'ing passthrough commands. Most or all headsets are going to be sending passthrough only, but we will nak other commands when I figure out how the nak looks.
If you have avrecv running when you start sending audio to the set, the headset will turn around and make the avrcp connection. I don't know how you use the play button to *initiate* the player however... :(
sounds promising. Keep up with it.
Quoted 8 lines
I would like to make this app a multithreaded daemon and hook it up to dbus for both receiving events from headsets and relaying things back to the headset (eg volume changes). I will run one thread per connection and
select()between data from the headset and dbus commands for the same l2cap connection...Does the dbus approach sound reasonable? Any tips for where to start with dbus? (I've never written for it)
I think it is far to earlier to think about D-Bus integration.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
Quoted 4 lines
Quoted 2 lines
I have my test app ("avrecv") accepting connections and ack'ing passthrough commands.
sounds promising. Keep up with it.
Ok, well I found almost everything I need. The only thing I'm not finding is the format for a volume up/down sent back to the headset. Have you seen with your sniffer what those frames look like?
I'm assuming it's also sent as a passthrough to the panel device but I'm guessing/experimenting to find the value of the volume up/down operands :(
Passthrough may not be right for volume changes... the headset neither acks nor naks those commands sent to its panel.
Quoted 1 line
I think it is far to earlier to think about D-Bus integration.
Fine. Once we have real a2dp alsa integration then it'll be more clear how avrcp fits in.
brad
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel