Jim > 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. a2dpd/headsetd functions are being combined & rewritten inside bluez-utils. the new daemon is minimalist--it only does connection management and hands over a writable (+readable for voice) fd to something that plugs into the audio system. the fd is passed around using a unix socket. > "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 new audio server has the basic parts of the dbus api working and is limping along with an alsa plugin. > 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. bluez uses dbus for all kinds of stuff. I've heard HAL should be involved and I've also heard it shouldn't. Do we use HAL to announce that a server has appeared on the LAN with an audio service? Bluetooth audio is similar in so many ways to a network audio service. Brad
