On Tue, 31 Jul 2007, Brad Midgley wrote: > Which module would be the best example for writing a bluetooth module? > It will link up our recent work in bluez on a bluetooth audio server > with a native pulse module. I'm totally over my head here, but I'll maunder: it sounds like you want to take module-alsa-sink (also source), rip out all the ALSA interface, and replace it with the guts of a2dpd. Possibly in the form of a shared library, which could also be used in the standalone a2dpd. > We have dbus messages to indicate a new headset appearing and dbus > interfaces to query and attach headsets. We then use a unix socket to > the bluez server to get a file descriptor for sending audio to the > current adapter. "We have" means "we will have" rather than "we already have", right? If the idea is to maintain the separate process for a2dpd... I think what you propose would be reasonable, particularly if a2dpd passed the writing end of a pipe as a FD over some socket. Or would it be sufficient if a2dpd just provided a UNIX domain socket on which it listened? And similarly for whichever daemon does SCO; I forgot its name. The dbus messages wouldn't be limited to just headphones, would it? This sounds like a job for HAL. Or am I describing what already exists? It also seems like a HCI-level activity, not specific to the two audio daemons. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc at math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)
