Re: Bluetooth questions from a bluetooth guy [Was: collaborating on bluetooth audio]
Fabien An interesting development has made it clear that your flowcontrol work and sco audio server are relevant for neo: http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=583 any sort of voice application like voip will have to use sco over hci because of limitations in the codec connected to the bluetooth adapter. It's a good thing neo has an adapter (csr) that is proven for this kind of stuff. Brad ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth questions from a bluetooth guy [Was: collaborating on bluetooth audio]
Henryk fyi, some related stuff came up in the bossa conference in Brazil last week: INdT people fixed our 32-bit sbc codec so it no longer has the problems of overflows popping and the volume being too low. I think we can now be satisfied that it runs correctly and do further optimization as needed... and the university INdT works with is considering putting students on the problem of porting the codec to the TI dsp. This doesn't really help openmoko in its current form but it is nice for maemo at least. We also discussed the audio architecture plan. My slides are at http://www.xmission.com/~bmidgley/soundingblue.pdfhttp://www.xmission.com/%7Ebmidgley/soundingblue.pdfwhile I find a better spot. Brad ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth questions from a bluetooth guy [Was: collaborating on bluetooth audio]
Moin, Am Tue Feb 13 19:18:28 2007 schrieb Fabien Chevalier: Brad, i was about to poke the list for some Bluetooth question, it looks like you were faster than i was ;-) Nice to see some familiar names :-) Brad's questions brings up even some more questions. Brad is talking about a2dp which should really be cool to have on OpenMoko platform Yeah, I want to have A2DP, too. Some other questions that i would be very happy to have answers for : * Which bluetooth chip will you use? Which version (1.2 or 2.0 ?) See http://wiki.openmoko.org/wiki/Neo1973_Hardware#Bluetooth and http://wiki.openmoko.org/wiki/Wishlist:Neo1973_P0_Review#Hardware_Information There's a Bluecore4 (Bluetooth 2.0+EDR) connected through USB which has audio from the Wolfson codec through PCM. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: collaborating on bluetooth audio
Brad Midgley skrev: Koen After reading the LCA slides on pulse-audio it seems to be the best choice for an audiorouting app FYI, I mocked up some diagrams including one that incorporates pulse. I am hoping to have some of these ideas validated, so let me know if you have any thoughts on it. http://bluetooth-alsa.sourceforge.net/future.html#pulse I like the use of D-bus for finding out whats there and hove to use it. But there really should be *one* audio connection manager. Were I can find a headset whether it is connected by usb or blutooth or anything else. And find out hove to connect to it (preferably in many ways, ie: hove to build a gst stream, hove to connect by pulse, hove to get a dsp interface, hove to get at it with alsa, hove to get at it by some lowlevel interface (eg: by blutooth directly). So an app can choose to connect the best way it know. For apps that don't care much for latency, it shuld be possible streaming the sound by D-bus, encoded with mimetype, or tell the D-bus service to play a file with (optionally?) given mimetype. Record to a file or D-bus stream into given mimetype. Then those apps only need to know hove to talk D-bus to get sound support. Don't need to know anything about encoders or conections, just ask the system what is supported. That gives a few D-bus services: General audio connection mgt, possably xfer agent. Blutooth audio device discovery agent. USB audio device discovery agent. Build audio connection service (possably several different 'protocol'/sources/targets). Support for mixer to? D-bus audio sink (passably several different for different formats - destinations). Support volume? D-bus audio source (passably several different for different formats - source). Support volume? This can be implemented in one demon, in several demons, inside other demons (like ones who discover other usb/blutooth devices). D-bus activation should let the app just talk to the D-bus interface the General audio connection manager point it to. Even pulse could be started on demand if we want :-) It need not be implemented in one shot ether. It's possably starting out supporting, say, only pulse and only main audio and blutooth. But USB shuld be a priority too. The D-bus audio sink/source may be left to more advanced media player apps/libs to implement. The audio connection mgr only need interface to register services and offer them. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: collaborating on bluetooth audio
Koen After reading the LCA slides on pulse-audio it seems to be the best choice for an audiorouting app FYI, I mocked up some diagrams including one that incorporates pulse. I am hoping to have some of these ideas validated, so let me know if you have any thoughts on it. http://bluetooth-alsa.sourceforge.net/future.html#pulse The picture has gotten really busy with everything elaborated but hopefully everyone gets the idea. Brad ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: collaborating on bluetooth audio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brad Midgley schreef: Koen What's the openmoko developers' take on pulseaudio? I'm looking at how a bluetooth pulse plugin would work out. fwiw, pulse could run as its own service or be embedded in another service. In terms of audiorouting, wouldn't a gstreamer based solution be more flexible? pulse provides some things we can use * allows for dynamically switching between audio adapters that come and go * has some work on low-latency for voice * as a daemon it can provide mixing and bluetooth connection persistence between multiple client shutdown/startup/etc. After reading the LCA slides on pulse-audio it seems to be the best choice for an audiorouting app, BUT ... ... it uses libsamplerate, which is doing heavy floating point math for each needed step, so it isn't usable on regular ARM cpus. If we can avoid samplerate conversion, it should be performing quite well on the intended hardware. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFsBBdMkyGM64RGpERAjzFAJ9UMHY/gQfA54I5NksKfBbpiHSOMQCgqzRH PEvosAsirpxYShcQeuSliJ8= =sNiS -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: collaborating on bluetooth audio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brad Midgley schreef: Hi I'm working on bluetooth audio--see bluetooth-alsa.sf.net http://bluetooth-alsa.sf.net. What sort of software are you using for bluetooth voice? Is it combined into some other services or standalone? We're also working on a2dp--our plan is to have one service running both voice and a2dp. Obviously it would be great for openmoko to have a2dp eventually. What's the openmoko developers' take on pulseaudio? I'm looking at how a bluetooth pulse plugin would work out. fwiw, pulse could run as its own service or be embedded in another service. In terms of audiorouting, wouldn't a gstreamer based solution be more flexible? regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFq8TrMkyGM64RGpERAuoxAJ91fyGn0z6TJJlIeFd+vwLmLX3DHwCdEgbT B08gY1/dATiYaa+rEZn1auM= =Pjgp -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Bluetooth questions from a bluetooth guy [Was: collaborating on bluetooth audio]
Hi all, Brad, i was about to poke the list for some Bluetooth question, it looks like you were faster than i was ;-) For those who don't know me (everybody, i guess ;-) ), i'm working with the Bluez guys(including Brad ;-) ) on integrating Voice headsets support under Linux. This kind of support is the basic profile that every Bluetooth phone ships with. However given the fact our projet is still quite immature i wouldn't be surprised if there was no support for voice headsets in the Neo *at all*. Am i right ? Brad's questions brings up even some more questions. Brad is talking about a2dp which should really be cool to have on OpenMoko platform (Allows listening to high quality music with appropriate headset). However this brings me to ask the following question : will the Neo even ship with a Media Player ? (It doesn't seem to be advertized in the apps list :-( ) Some other questions that i would be very happy to have answers for : * Which bluetooth chip will you use? Which version (1.2 or 2.0 ?) * Which profiles to you intend to support in the initial release ? Cheers, Fabien PS: Of course, as soon as the Neo is out, i'm gonna purchase the hacker's kit and see how bluetooth support can be improved ;-) Hi I'm working on bluetooth audio--see bluetooth-alsa.sf.net http://bluetooth-alsa.sf.net. What sort of software are you using for bluetooth voice? Is it combined into some other services or standalone? We're also working on a2dp--our plan is to have one service running both voice and a2dp. Obviously it would be great for openmoko to have a2dp eventually. What's the openmoko developers' take on pulseaudio? I'm looking at how a bluetooth pulse plugin would work out. fwiw, pulse could run as its own service or be embedded in another service. Brad ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: collaborating on bluetooth audio
Koen What's the openmoko developers' take on pulseaudio? I'm looking at how a bluetooth pulse plugin would work out. fwiw, pulse could run as its own service or be embedded in another service. In terms of audiorouting, wouldn't a gstreamer based solution be more flexible? pulse provides some things we can use * allows for dynamically switching between audio adapters that come and go * has some work on low-latency for voice * as a daemon it can provide mixing and bluetooth connection persistence between multiple client shutdown/startup/etc. Is there a similar gstreamer server out there or are you suggesting a new project? Brad ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
