From: Brad M. <bmi...@xm...> - 2005-08-18 17:14:33
|
Guys, I exchanged email with the Ericsson tech contact for gumstix a while back and determined there was no hci routing of audio so SCO audio on gumstix would always terminate at the (unconnected/unreachable) pcm lines. An interesting post showed up at the bluez-devel list yesterday: ======================================== i'm using an ericsson "ROK 101008" bluetooth module and kernel 2.6.10. the module can be connected via usb or rs232. and i found an ericsson specific hci command to switch the sco-path to HCI (it is set to PCM by default). using the usb connection (hci_usb) everything works fine and i can send and receive audio to/from a headset. however, when connecting the module via serial cable (hci_uart) sending and receiving audio does not work. the sco connection to the headset is established but there is no sco data transferred. i tried to attach the device with different speeds but i did not notice any difference. i really need the serial connection because usb is not available on the target system. can somebody help me with this topic? ======================================== I'd love to find out I was wrong on this. I replied to him but haven't gotten anything back yet. Very interesting. I'll try to find out more. Brad |
From: Craig H. <cr...@gu...> - 2005-08-18 17:59:43
|
They're end-of-lifing the ROK104001, so we're going to be moving to using the replacement PD-something module, which has a different footprint, so we're going to have to redo the BT pad section of the gumstix anyway -- when we do, we'll connect the module's PCM lines to one of the SSPs on the PXA. Then PCM data should be readable using the SSP. It would of course be neat if the module *could* do PCM-over-HCI. C On Aug 18, 2005, at 8:10 AM, Brad Midgley wrote: > Guys, > > I exchanged email with the Ericsson tech contact for gumstix a > while back and determined there was no hci routing of audio so SCO > audio on gumstix would always terminate at the (unconnected/ > unreachable) pcm lines. An interesting post showed up at the bluez- > devel list yesterday: > > ======================================== > i'm using an ericsson "ROK 101008" bluetooth module and kernel > 2.6.10. the module can be connected via usb or rs232. and i found > an ericsson specific hci command to switch the sco-path to HCI (it > is set to PCM by default). > > using the usb connection (hci_usb) everything works fine and i can > send and receive audio to/from a headset. however, when connecting > the module via serial cable (hci_uart) sending and receiving audio > does not work. the sco connection to the headset is established but > there is no sco data transferred. i tried to attach the device with > different speeds but i did not notice any difference. i really need > the serial connection because usb is not available on the target > system. can somebody help me with this topic? > ======================================== > > I'd love to find out I was wrong on this. I replied to him but > haven't gotten anything back yet. Very interesting. I'll try to > find out more. > > Brad > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/ > bsce5sf > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Brad M. <bmi...@xm...> - 2005-08-20 20:54:35
|
Craig > They're end-of-lifing the ROK104001, so we're going to be moving to > using the replacement PD-something module, which has a different > footprint, so we're going to have to redo the BT pad section of the > gumstix anyway -- when we do, we'll connect the module's PCM lines to > one of the SSPs on the PXA. Then PCM data should be readable using the > SSP. I'm very glad to hear that. I'd be interested to see datasheets etc for the PD-xx module when you've settled on something. Brad |
From: Craig H. <cr...@gu...> - 2005-08-21 00:27:07
|
On Aug 20, 2005, at 1:54 PM, Brad Midgley wrote: > I'm very glad to hear that. I'd be interested to see datasheets etc > for the PD-xx module when you've settled on something. I think the datasheets are all on the infineon website. Go to bluetooth modules, and then click through and it gives you all the stuff, looks like. C |
From: Brad M. <bmi...@xm...> - 2005-08-23 21:10:00
|
Craig, Ok, I found some docs at infineon.com. Are you using the newer PBA31307 with bluetooth 1.2? That will be better than the '305 model esp. for coexisting with wifi. The "migrating" document has the tantalizing "4.3 Sco data over HCI-UART The Singlestone module supports up to two SCO (HV3) links over the UART." But no other mention. Then the datasheet mentions the infineon has its own extensions to HCI but does not elaborate :( Brad Craig Hughes wrote: > On Aug 20, 2005, at 1:54 PM, Brad Midgley wrote: > >> I'm very glad to hear that. I'd be interested to see datasheets etc >> for the PD-xx module when you've settled on something. > > > I think the datasheets are all on the infineon website. Go to > bluetooth modules, and then click through and it gives you all the > stuff, looks like. > > C > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Craig H. <cr...@gu...> - 2005-08-23 22:34:42
|
On Aug 23, 2005, at 2:09 PM, Brad Midgley wrote: > Craig, > > Ok, I found some docs at infineon.com. Are you using the newer > PBA31307 with bluetooth 1.2? That will be better than the '305 > model esp. for coexisting with wifi. Yes, the 31307 is the plan. > The "migrating" document has the tantalizing > > "4.3 Sco data over HCI-UART > The Singlestone module supports up to two SCO (HV3) links over > the UART." > > But no other mention. Then the datasheet mentions the infineon has > its own extensions to HCI but does not elaborate :( Yeah, the docs for that come with the modules I expect. Should be pretty straightforward I expect. We'll connect the PCM to the SPI bus anyway which will probably give higher throughput and almost certainly use far less CPU. C |
From: Brad M. <bmi...@xm...> - 2005-08-24 00:06:04
|
Craig > Yeah, the docs for that come with the modules I expect. Should be > pretty straightforward I expect. We'll connect the PCM to the SPI bus > anyway which will probably give higher throughput and almost certainly > use far less CPU. SCO through PCM is also designed for low latency so this method should beat all the hci transport methods in response time. The only way it would be better than this would be to go around the cpu rather than through it :) Brad |
From: Craig H. <cr...@gu...> - 2005-08-24 01:07:40
Attachments:
pastedGraphic.tiff
|
On Aug 23, 2005, at 5:05 PM, Brad Midgley wrote: > Craig > > >> Yeah, the docs for that come with the modules I expect. Should >> be pretty straightforward I expect. We'll connect the PCM to the >> SPI bus anyway which will probably give higher throughput and >> almost certainly use far less CPU. >> > > SCO through PCM is also designed for low latency so this method > should beat all the hci transport methods in response time. The > only way it would be better than this would be to go around the cpu > rather than through it :) Yeah, but I'm guessing that some reasonable percentage of the time, you'll want to do something with the PCM stream, like record it or generate it from an MP3 file or something, so going around it would just be more of a pita. And there's no "PCM in" on the ucb1400, or any other codec I could find which might more or less drop in as a replacement for the ucb1400. I think a great solution would potentially be: |
From: Doug S. <do...@pr...> - 2005-08-24 01:24:03
|
Craig Hughes wrote: > there's no "PCM in" on the ucb1400, or any other codec I could find There are a few, see WM9713, WM9714, WM8753, and LM4930. These are all dual codecs, one for HiFi (either I2S or AC97) and one for voice (PCM) which could also be used for bluetooth. The wolfson codecs are very high quality, very flexible, and low power. I have some here but I'm in the process of getting set up for reflow soldering so it will be a while before I actually try them. All of these codecs are QFN package (no exposed leads). -- Doug |
From: Craig H. <cr...@gu...> - 2005-08-24 15:52:15
|
On Aug 23, 2005, at 6:19 PM, Doug Sutherland wrote: > Craig Hughes wrote: > > > there's no "PCM in" on the ucb1400, or any other codec I could find > > There are a few, see WM9713, WM9714, WM8753, and LM4930. These are all > dual codecs, one for HiFi (either I2S or AC97) and one for voice (PCM) > which could also be used for bluetooth. The wolfson codecs are very > high quality, very flexible, and low power. I have some here but I'm > in the process of getting set up for reflow soldering so it will be a > while before I actually try them. All of these codecs are QFN package > (no exposed leads). Thanks Doug -- Gordon and I will take a look. C |
From: Doug S. <do...@pr...> - 2005-08-24 17:57:21
|
Craig, The interesting thing about these dual codecs is that the HiFi codec interface (I2S or AC97) data can be sent over the PCM (bluetooth) and vice versa. This allows the host to do things like play mp3 but also deal with phone calls over the PCM interface. The wolfson codecs also have mixing capability, each codec has a PGA (programmable gain amplifier), and they have ALC (automatic level control) capability for recording incoming calls, and sidetone path so you can hear what you say on the phone etc. The problem wrt gumstix is that bluetooth is on the CPU module, but there is only one audio port exposed on the connector. So to connect a dual codec, either both bluetooth and audio codec would have to be on the CPU module, or the connector would have to have both the Hifi (AC97/I2S) and Voice (PCM) signals (allowing both to be external). My plan is to try an external bluetooth module and external dual audio codec. -- Doug Craig Hughes wrote: > On Aug 23, 2005, at 6:19 PM, Doug Sutherland wrote: > >> Craig Hughes wrote: >> >> > there's no "PCM in" on the ucb1400, or any other codec I could find >> >> There are a few, see WM9713, WM9714, WM8753, and LM4930. These are all >> dual codecs, one for HiFi (either I2S or AC97) and one for voice (PCM) >> which could also be used for bluetooth. The wolfson codecs are very >> high quality, very flexible, and low power. I have some here but I'm >> in the process of getting set up for reflow soldering so it will be a >> while before I actually try them. All of these codecs are QFN package >> (no exposed leads). > > > Thanks Doug -- Gordon and I will take a look. > > C > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > |
From: Craig H. <cr...@gu...> - 2005-08-24 22:24:54
|
On Aug 24, 2005, at 10:52 AM, Doug Sutherland wrote: > The interesting thing about these dual codecs is that the HiFi > codec interface > (I2S or AC97) data can be sent over the PCM (bluetooth) and vice > versa. This > allows the host to do things like play mp3 but also deal with phone > calls over > the PCM interface. The wolfson codecs also have mixing capability, > each codec > has a PGA (programmable gain amplifier), and they have ALC > (automatic level > control) capability for recording incoming calls, and sidetone path > so you can > hear what you say on the phone etc. The problem wrt gumstix is that > bluetooth > is on the CPU module, but there is only one audio port exposed on > the connector. > So to connect a dual codec, either both bluetooth and audio codec > would have > to be on the CPU module, or the connector would have to have both > the Hifi > (AC97/I2S) and Voice (PCM) signals (allowing both to be external). > My plan is > to try an external bluetooth module and external dual audio codec. Well, the connector *would* have both sets of signals. The AC97 as is, and the PCM data would go over one of the sets of SSP lines (probably the SSP rather than the NSSP). That way you can use the gumstix as something like a fancy answering machine w/out the audiostix mk2 (by just reading/writing the PCM via SSP from the PXA), or you can use it as a computer-assisted headset by using AC97 to tell the audiostix mk2 what to do with the audio. C |
From: Brad M. <bmi...@xm...> - 2005-08-24 04:22:47
|
Craig > Probably easiest to just go through the PXA > after all. I'd agree with that. When this comes together we need to come up with a driver strategy. The lightweight solution is to keep the btsco daemon around and provide a new kernel audio driver that sends messages to the daemon for connect/disconnect and passes audio to the right PCM interface. The other bluez developers and I are actually trying to get away from audio code in the kernel in general and use the userspace alsa drivers. However, for gumstix that doesn't fit well with the PCM approach and it requires a lot of flash for the alsa lib. Brad |
From: Craig H. <cr...@gu...> - 2005-08-24 15:52:10
|
> The other bluez developers and I are actually trying to get away > from audio code in the kernel in general and use the userspace alsa > drivers. However, for gumstix that doesn't fit well with the PCM > approach and it requires a lot of flash for the alsa lib. Gumstix will be switching to the ALSA drivers for the AC97 stuff once I get off my lazy butt and do it. C |