Thanks Leszek, you were right. I didn't need to be bothering with hcitool =
etc at all. The Gnome applet had me sorted all along. I guess my understa=
nding stemmed from reading too many out-of-date web pages.
A new challenge for the readers of the mailing list: getting the bluetooth =
headset's microphone working with Twinkle.
Twinkle is software I use to access my VOIP account (phone line). I am abl=
e to hear the people I talk to with Twinkle through the bluetooth headset h=
aving having (A) created a ~/.asoundrc as explained in http://wiki.bluez.or=
g/wiki/HOWTO/AudioDevices and (B), in Twinkle, opened Edit> System Settings=
...> Audio and, for Speaker, selected "ALSA: other device" and then entered=
in the "Other device" field: the word "bluetooth".
The sound from Twinkle comes through the headset loud and clear.
I tried the same for the Microphone: I selected "ALSA: other device", and i=
n the corresponding "Other device" field, I entered the word "bluetooth". =
But, after making those settings, no one can hear anything I'm saying throu=
gh the headset and Twinkle. Hmmmmm.
_________________________________________________________________
Climb to the top of the charts!=A0Play the word scramble challenge with sta=
r power.
http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_jan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
While we're on the topic of VoIP applications, I'm curious if anybody
has successfully combined Bluez's ALSA plugin with ALSA slave devices.
There's a VoIP app that I'd like to use with my headset that only
supports a 32kHz sampling rate. Because my bluetooth headset (using
"headset" profile) only supports an 8kHz sampling rate, I tried to use
an ALSA plugin for realtime rate conversion. This ALSA plugin works
perfectly with my main soundcard (emu10k1), but fails with the bluetooth
device.
I have defined the ALSA plugin to use the bluetooth device:
pcm.bluetooth {
type bluetooth
device 00:16:8F:08:8F:80
profile "auto"
}
pcm_slave.rate {
pcm bluetooth
format S16_LE
channels 1
rate 8000
}
pcm.complex_convert {
type plug
slave rate
}
ALSA doesn't seem to be the culprit, because defining the slave PCM with
"hw" as the master device instead of "bluetooth" will downsample any
incoming sound stream to 8kHz. But when I try using the device with my
bluetooth device, e.g.:
$ aplay -D 44100.wav
Playing WAVE '44100.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
The headset produces a buzzing noise (sounds like a 1kHz square wave),
and causes my system to hard lock a few seconds after aplay finishes.
Is there a known compatibility issue between Bluez and ALSA plugins? If
it's guaranteed to not work, would a sound daemon like Pulseaudio be a
decent compromise for realtime rate conversion?
Cheers,
Chip McArtor
Guys
It is useful to have bug reports using something we can examine and
debug like twinkle/ekiga.
One area you could explore is whether pulse in the middle changes the
result. (example on
http://wiki.bluez.org/wiki/HOWTO/AudioDevices#Tryingpulse ) If you
have pulse running correctly that is... the example won't work for me
in my (older) pulse build.
Brad
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
I have a similar situation with Ekiga. Skype users also complain. AFAIK,
using a bluetooth headset with any VoiP-like softphone is currently not
working in Linux.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
mountain rides schrieb:
>
> A new challenge for the readers of the mailing list: getting the bluetooth headset's microphone working with Twinkle.
>
> The sound from Twinkle comes through the headset loud and clear.
>
> I tried the same for the Microphone: I selected "ALSA: other device", and in the corresponding "Other device" field, I entered the word "bluetooth". But, after making those settings, no one can hear anything I'm saying through the headset and Twinkle. Hmmmmm.
>
Same situation here. arecord works flawlessly, but the other end of a
VOIP connection through twinkle only gets loud white noise from my side.
There's actually a discussion about that on the twinkle mailing list and
the developers there are pretty sure it's a timing problem. twinkle is
rapidly opening and closing the alsa input device during a connection
and it seems, the closing of the bluetooth device returns asynchronously
and later than the next subsequent open instruction. That's at least my
limited understanding of the problem.
The twinkle guys are suspecting a bug in the bluetooth audio
implementation, see the following quote from the ongoing discussion:
<quote>
bluetooth has problems with twinkle!
Anyway, rapid closing and reopening a handle isn't anything rogue at all. If
this is the source of the problem, it's clearly a bug in ALSA stack resp. the
bluez/pulseaudio plugins. Those plugins have to handle any timing issues with
their associated hardware. You never can guarantee that such a close-open
sequence never will occur, from *any* app - just twinkle is doing this
frequently. It's up to the bluez devs to write a (twinkle-inspired?)
testframe to provoke this error, and to harden their plugin so it handles
this correctly. I.E close() MUST NOT return premature (alias async), and
open() maybe has to wait until any "pending" close() has finished inside
driver.
</quote>
So, now, we are at least two people with the same problem - maybe anyone from the bluez side will finally have a look into this matter now.
cu
Wolfgang
--
Geek by nature, Linux by choice
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On February 19, 2008 05:58:53 pm Wolfgang Wershofen wrote:
> Anyway, rapid closing and reopening a handle isn't anything rogue at all.
There was a fix committed to utils CVS not too long ago (1 week, maybe 2)
which fixes this by waiting a few seconds before actually closing down the
audio link to the headset. It certainly solved my Twinkle problems.
Twinkle also released a new version last week which doesn't rapidly close and
reopen the audio device, so the problem has been fixed from both sides.
Regards,
Andrew
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users