This is cool stuff. Thanks to everyone who's working on it.

I have a Samsung T10. I have thought about using the N8x0 as a speaker set for it. I thought about perhaps working with the author of BlueMaemo, however. I have had a peek at the code (briefly) and it looks like it's doable.

BlueMaemo is in Python. It looks like the code you are working with right now is not.

What do you folks think?

message from Sam as promised earlier... I have cut out some of my waffle.


Thanks for your note! I took a look at that thread and think it's pretty cool that you guys managed to get it to run in the tablet environment.

I made a few changes to SVN based on MrWeasel's comments, including hopeful solutions for the dbus_watch_get_unix_fd() issue and the PyGTK set_tooltip_text() method being missing. I'm curious whether the changes fix his two issues, so please forward this on!

Man, you guys think of the most interesting ways of applying this technology! Up until today I wasn't sure why anyone would ever want to run a hands-free on a tablet. Being able to leave the phone in your pocket and do everything with the tablet is compelling, perhaps much more so than using hands-free on a desktop. Very cool!

[snip]

Nokia-N800-36-5:/usr/bin# hfconsole
python[1781]: GLIB WARNING ** libglade - unknown property `program_name' for class `GtkAboutDialog'
python[1781]: GLIB WARNING ** libglade - could not convert string to type `GStrv' for property `authors'


This is fishy, it looks like the Glade UI definition must include some properties that don't exist in your version of Gtk+. Do you know what version of Gtk+ you're using?


/usr/bin/hfconsole:220: Warning: gsignal.c:1617: signal `file_set' is invalid for instance `0x25f050'
self.widgets.signal_autoconnect(dic)


This looks like another Gtk+ feature that changed in a more recent version.


HFPD: >> +CIND: ("service",(0,1)),("call",(0,1)),("callsetup",( 0-3)),("call_setup",(0-3)),("callheld",(0-2)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5))


Nice phone :P Look at all those indicators it supports!


HFPD: Pump: packet size = 24
HFPD: Pump: input max fill = 320
HFPD: Pump: bot packet size = 160
HFPD: Pump: bot min fill = 320
HFPD: Pump: bot max fill = 640
HFPD: Pump: top packet size = 24
HFPD: Pump: top min fill = 48
HFPD: Pump: top max fill = 96


The buffer fill level constraints for the top endpoint (the phone) are a bit small. Try opening the properties page, and setting the packet size to 20ms and the buffer fill level to >=40ms. This should also be fixed in current SVN -- the configuration code now considers the packet size of both endpoints when choosing a default fill level for each.

Thanks again! I'll be paying attention to what you guys are up to with this, and please let me know if I can be of service.

-Sam

additional email from Sam

Traceback (most recent call last):
File "/usr/bin/hfconsole", line 1161, in config_driver_changed
devlist = self.soundio.ProbeDevices(drivername)
File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 607, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: Device probe failed


Hi Gary,

In current SVN, the exception above should now be caught and details written to the console. I'm not sure of the exact cause, but will guess that the enumeration API in alsa-lib must be failing. If you get a chance to run the latest SVN, let me know if you get any 'Device probe failed' messages to the console output.


Traceback (most recent call last):
File "/usr/bin/hfconsole", line 1044, in config_open
self['ConfigDriverOpts'].set_text(savecfg['driveropts'])
AttributeError: 'NoneType' object has no attribute 'set_text'


This would appear to be another issue with the Gtk+ infrastructure and how the Glade UI definition is processed. The good news is, there appears to be a clear workaround. I just committed it to SVN. If you get a chance, let me know if you continue to see this problem.

At first, big thanks to Sam for your support!

I've tried the recent code from svn. Now it compiles and runs without any code changes necessary, good job!

The bad news is, that there is still no sound. Every time I either try to do a call or to do the feedback test I get a "Primary Sound Card Failure".

I guess Sam is reading this, so I've attached the logs for both, trying to make a call and the feedback test (removed my mac and phone number ). Tried this with different settings for "Packet Interval" and "Output Buffer" with no success. It seems that there is a general problem with accessing the sound card..

P.S.: Actually I didn't want to mention it, but I've tried hfconsole in the deblet chroot, since I read about them having set up a proper ALSA system.
There I get at least a noise (and nothing more) from the speakers when I do the feedback test. The bad news is that in the chroot it won't even detect the bluetooth (reports a problem connecting to SDP, even though "hcitool scan" works), which makes things worse I think ... :/

Hi MrWeasel,

I looked at your console output, and am puzzled by the following:

This is the audio device watchdog observing a lack of progress. But let's get back to that issue because something else is broken. It should have hit the underprocessing condition three times before failing the device. At that point it should have failed the device as underprocessing, not overprocessing. So, because this problem is not reproducible on my desktop or car PC, I committed some more changes to SVN to try to shed some light. Give it another whirl with the latest.

BTW, do you get any build warnings?

Hopefully we'll get this thing to work real soon!

Thanks!

Okay, here we go again.
(Sound card failure is still present, but now with a nice exclamation mark in the prefs dialog )


I don't seem to get any build errors, the only thing I get are these things from autogen.sh:

As for the GTK+ version, I found the following:

libgtk1.2 1.2.10-18.1-maemo.2.n800
libgtk2.0-0 2.10.12-0osso36


Log from attempt for feedback test is attached.

Hi MrWeasel,

This makes more sense now, and should be fixed. In the future, when I test on x86, I will include builds compiled with -funsigned-char. Try the latest out of SVN, maybe now we can finally get to the bottom of the audio input problem.

Thanks!

It's now refusing to build for me now, using svn revision 43 with the following errors

[sbox-DIABLO_ARMEL: /usr/src/trunk] > ./autogen.sh
/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/a...ding%20aclocal
configure.in: installing `./install-sh'
configure.in: installing `./missing'
hfpd/Makefile.am: installing `./depcomp'
configure.in:22: error: possibly undefined macro: AC_PROG_CXX_C_O
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:35: error: possibly undefined macro: AC_TYPE_SSIZE_T
configure.in:36: error: possibly undefined macro: AC_TYPE_UINT16_T
configure.in:37: error: possibly undefined macro: AC_TYPE_UINT32_T
configure.in:38: error: possibly undefined macro: AC_TYPE_UINT8_T

I noticed from on of your mp3car forum posts Sam that you have a VM enviroment. there is a VMware appliance with a build enviroment form the tablets which may be worth checking out. It's what I use, and the link is http://maemovmware.garage.maemo.org/

From my experience with Debian on the tablets, if you can support ESD, you're much more likely to have success than with ALSA.

This looks really cool.

these are just autogen.sh errors, ignore them and go on with ./configure and then make, it's still working for me.

Ok, so here we go again. The good news are: It's now working A LOT better than before! This was the first time I got "sound" from the program, so it seems to find a way to the sound device now.
The bad news are, that (similar to my experience in the deblet chroot) the sound from the loopback test works only from time to time, and when it does it comes with a delay of 4-5 seconds and only for a duration of ~1 second.
Also it's not possible to exit the loopback test, once started it "works" for some time (crappy sound) then seems to hang. This resulted in a funny experience hearing my voice from the tablet speakers after the program itself was already closed! (maybe because of the hfpd running in the background ?).

EDIT: Ok, left it at the hanging state while writing this and it recovered and worked again.

During the test, from time to time warning messages appear, but I wasn't able to read them compleately, because they disappear quickly (something like "Soundcard capture playback skew.... 96")
These occasions also seem to be the moments when I can hear sound from the speakers.

I tried with different settings for buffer and packet size, but with no success..

It seems to me that this is some kind of performance issue, but I'm not sure what is causing this, because the CPU load keeps down during the feedback test.. not sure about the dsp load anyway..


When making a call the behavior also made a progress. This was the first time i read "audio open" in the hfconsole window! But shortly after that, again the bluetooth connection is disconnected, and I'm not hearing any sound from the phone through the speakers...

I tried to describe this weired behaviour as detailed as possible, I hope it makes some sense to you samr7 (or to somebody else?)

As usual, the logs are attached =)
(just in case you wonder, in the feedback log, I was playing with the "output buffer")

I'm still getting the problem from line 1044 in hfconsole as below when I try to enter preferences. It kinda works if I comment it out, but then I get "cannot apply sound driver settings" when tying a sound test or changing a setting.

Traceback (most recent call last):
File "/usr/bin/hfconsole", line 1044, in config_open
self['ConfigDriverOpts'].set_text(savecfg['driveropts'])
AttributeError: 'NoneType' object has no attribute 'set_text'

Other than that this is starting to sound really exciting. Thanks to everyone working on this.

Gaz