[pulseaudio-discuss] Clicks or buzzing on Bluetooth

[Brad Midgley]

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