[pulseaudio-discuss] Clicks or buzzing on Bluetooth
bmidgley at gmail.com
Tue Jul 31 12:18:31 PDT 2007
> 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
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
More information about the pulseaudio-discuss