To be a bit more specific: I'm now running a kernel built from the ubuntu.com git repository, with the specified patch applied. From there I've built and installed binary-generic.
The BT-handsfree-kit works (kind of) with this kernel.
While running with this kernel I've seen bt-audio once end up in a weird state where it repeats the following to syslog:
When this happened mplayer reported the following while trying to open the bt-device:
[AO_ALSA] pcm prepare error: Invalid argument
[AO_ALSA] Write error: Bad file descriptor
[AO_ALSA] Trying to reset soundcard.
[AO_ALSA] alsa-lib: pcm_bluetooth.c:1481:(audioservice_expect) Bogus message BT_STREAMSTART_REQ received while BT_STREAMSTART_RSP was expected
---
Sound tends to break up regardless of the distance between the devices, so I've tried to install the most recent releases from bluez.org (bluez-libs-3.30, bluez-utils-3.30, bluez-firmware-1.2, bluez-hcidump-1.41, bluez-gnome-0.26). Unfortunately that makes no difference to sound quality. (Btw; nor is there yet anything that can help with the previously mentioned pairing issue for headsets). The new packages are built and installed on-top of the standard files from hardy to avoid loosing other bt-tools through dependencies (yes I'm aware of the consequences;). The only significant difference except bug-fixes seem to be that services now are plugins in the form of shared-libs and not separate processes as they used to be.
Next is to check for other kernel-patches. Now I wonder where the actual version of bluez-code in the current hardy-kernel comes from. It doesn't seem to match vanilla 2.6.24 from kernel.org, nor does it match the latest patches from bluez.org. It seems to be something in the middle.
---
I think BT-audio is going to be hard to solve in hardy for several reasons:
- bluez since release 3.26 (the one in hardy) is in a bit of a limbo. This is the first of the 3.x releases that are describes as part of a transition to new architecture in bluez 4.0
- kernel modules for alsa/bluez integration that supposedly are obsolete as of bluez 3.26 are still included in hardy
- then there is the incomplete alsa/pulseaudio transition.
Half-baked is probably an appropriate description.
To be a bit more specific: I'm now running a kernel built from the ubuntu.com git repository, with the specified patch applied. From there I've built and installed binary-generic.
The BT-handsfree-kit works (kind of) with this kernel.
While running with this kernel I've seen bt-audio once end up in a weird state where it repeats the following to syslog:
Apr 12 15:23:57 audio[14838]: Audio API: received BT_STREAMSTART_REQ
Apr 12 15:23:57 audio[14838]: Audio API: sending BT_STREAMSTART_REQ
When this happened mplayer reported the following while trying to open the bt-device:
[AO_ALSA] pcm prepare error: Invalid argument c:1481: (audioservice_ expect) Bogus message BT_STREAMSTART_REQ received while BT_STREAMSTART_RSP was expected
[AO_ALSA] Write error: Bad file descriptor
[AO_ALSA] Trying to reset soundcard.
[AO_ALSA] alsa-lib: pcm_bluetooth.
---
Sound tends to break up regardless of the distance between the devices, so I've tried to install the most recent releases from bluez.org (bluez-libs-3.30, bluez-utils-3.30, bluez-firmware-1.2, bluez-hcidump-1.41, bluez-gnome-0.26). Unfortunately that makes no difference to sound quality. (Btw; nor is there yet anything that can help with the previously mentioned pairing issue for headsets). The new packages are built and installed on-top of the standard files from hardy to avoid loosing other bt-tools through dependencies (yes I'm aware of the consequences;). The only significant difference except bug-fixes seem to be that services now are plugins in the form of shared-libs and not separate processes as they used to be.
Next is to check for other kernel-patches. Now I wonder where the actual version of bluez-code in the current hardy-kernel comes from. It doesn't seem to match vanilla 2.6.24 from kernel.org, nor does it match the latest patches from bluez.org. It seems to be something in the middle.
---
I think BT-audio is going to be hard to solve in hardy for several reasons:
- bluez since release 3.26 (the one in hardy) is in a bit of a limbo. This is the first of the 3.x releases that are describes as part of a transition to new architecture in bluez 4.0
- kernel modules for alsa/bluez integration that supposedly are obsolete as of bluez 3.26 are still included in hardy
- then there is the incomplete alsa/pulseaudio transition.
Half-baked is probably an appropriate description.