Re: [gta02-core] Audio rework

3 messages Options
Embed this post
Permalink
Werner Almesberger

Re: [gta02-core] Audio rework

Reply Threaded More More options
Print post
Permalink
[ Copying the hardware list since this has been researched thoroughly
  in GTA02 and GTA03. ]

Rene Harder wrote:
> I started already an ECN (ecn0010) with some notes and ideas what we
> need to change.

I added a bunch of ECNs for all the audio issues and tweaks I'm aware
of. If you're already covering them in ECN0010, I'd just withdraw mine
and you can list the items there. Perhaps the title of ENC0010 should
then become something like "Audio done right, at last" ;-)

The ECNs are:

0015    Edit    Remove Calypso serial interface on headset (U4401)
0018    Edit    Add beads/filters to audio signals leaving/entering can
0019    Edit    Consider applying buzz fix
0020    Discuss No common mode choke on stereo signals (B4102)
0021    Defer   Use EMI-hardened microphone (MC4301)
0022    Edit    Apply bass fix

> The removal of the external audio amp should not be a big problem we
> stay as close a possible to the reference design of wolfson.
> That means earpiece connected to OUT3 and ROUT1, headphone connected to
> ROUT1 and LOUT1, speaker connected to ROUT2 and LOUT2.

Yeah, that's exactly how it's done in GTA03-6410 as well. (Which is
Openmoko's latest design, so I hope it contains all the good stuff.)

> If we connect JACK_INSERT to the GPIO4 pin, the codec will switch
> automatically between earpiece and headset. However we still can select
> the output with the corresponding register settings of the codec.
> What do you think, is it necessary to do that in hardware?

Hmm, you mean that on jack removal/insertion, the codec would switch
automatically, the CPU would also get notified (via GPF4/JACK_INSERT),
plus there would be a way for the CPU to override the codec's decision ?

I'm not sure if the whole scenario is simple enough to do it in
hardware. E.g., connecting headphones indicates that the user may
be interested in cutting all audio that comes from speakers inside
the phone, but there may be exceptions as well.

> We increase the cap size to at least 100uF (better more). This results
> in a dramatically increased physical size of the capacitor. I think the
> maximum capacity for a common 1206 ceramic cap is [hidden email].
> (f_cutoff=50Hz @Z_headphone=32OHM and C=100uF)

In the GTA03-6410 design, I see a 47 uF cap on each channel,
following a bead.

> In this case we need
> to change the headset and jack to get a separate ground for headphone
> and microphone.

That sounds very messy, as headsets with separate ground may not
be readily available (do they even exist ?)

Alas, the ~1.3 V of bias we could get with headset ground at Vmid
doesn't seem to be enough for any microphone that would be remotely
suitable :-(

> Also in the GTA02 schematics there are 33 OHM resistors in series of the
> headphone stereo path, they will increase the lower cutoff frequency but
> will limit the maximum volume of the headphone.
> Although it will increase our lower cut off frequency, I think we should
> remove those completely. Also wolfson doesn't recommend any resistor in
> the headphone paths.

Could they be meant to offer some sort of short-circuit protection
during jack insertion and when pressing HOLD ?

> I would just delete all parts U4401,R4411 R4403, H-TP4406 and H-TP4405
> from the schematics to remove calypso serial interface on the headset
> jack. We might need to keep the pull down resistors (R4411 R4403), I've
> not checked that yet.

I think we need R4411 to keep RX_IRDA from floating, but all the
rest can go, uncluding the whole nDL_GSM net.

> Did i forgot anything else, maybe there are some problems which I'm not
> aware of?

I have some more:

- no common mode choke in the stereo path (B4102). That's a component
  change, so it may be too complicated for gta02-core, but we can at
  least earmark it. (ECN0020)

- there's a fancy new EMI-hardened microphone that comes in a square
  package instead of the round one. I'm not sure which one we'll get
  from Openmoko. The old one would be a little more convenient,
  since it doesn't require case-modding. (ECN0021)

- add beads to keep the RF out (ECN0018)

- I don't know if we'll still need to stabilize MICBIAS, aka apply
  the buzz fix, when all this is done. (ECN0019)

I hope that's all the critters we have on the audio side :)

- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Rene Harder

Re: [gta02-core] Audio rework

Reply Threaded More More options
Print post
Permalink
Werner Almesberger wrote:

> [ Copying the hardware list since this has been researched thoroughly
>   in GTA02 and GTA03. ]
>
> Rene Harder wrote:
>  
>> I started already an ECN (ecn0010) with some notes and ideas what we
>> need to change.
>>    
>
> I added a bunch of ECNs for all the audio issues and tweaks I'm aware
> of. If you're already covering them in ECN0010, I'd just withdraw mine
> and you can list the items there. Perhaps the title of ENC0010 should
> then become something like "Audio done right, at last" ;-)
>
> The ECNs are:
>
> 0015    Edit    Remove Calypso serial interface on headset (U4401)
> 0018    Edit    Add beads/filters to audio signals leaving/entering can
> 0019    Edit    Consider applying buzz fix
> 0020    Discuss No common mode choke on stereo signals (B4102)
> 0021    Defer   Use EMI-hardened microphone (MC4301)
> 0022    Edit    Apply bass fix
>
>  

My suggestion:

We keep the individual ECNs, in this way it's easier to have an overview
of the changes.
In the ECNs we shortly describe the reason/problem and refer to the ECN
with the name "global audio rework".
How does that sound?

>> If we connect JACK_INSERT to the GPIO4 pin, the codec will switch
>> automatically between earpiece and headset. However we still can select
>> the output with the corresponding register settings of the codec.
>> What do you think, is it necessary to do that in hardware?
>>    
>
> Hmm, you mean that on jack removal/insertion, the codec would switch
> automatically, the CPU would also get notified (via GPF4/JACK_INSERT),
> plus there would be a way for the CPU to override the codec's decision ?
>
> I'm not sure if the whole scenario is simple enough to do it in
> hardware. E.g., connecting headphones indicates that the user may
> be interested in cutting all audio that comes from speakers inside
> the phone, but there may be exceptions as well.
>  

Yes you can override this feature because you need to activate it first.
That's what the data sheet says:

"Pin 43 (GPIO4) can be used as a headphone switch control input to
automatically disable the speaker
output and enable the headphone output e.g. when a headphone is plugged
into a jack socket. In this
mode, enabled by setting HPSWEN, pin 43 switches between headphone and
speaker outputs (e.g.
when pin 43 is connected to a mechanical switch in the headphone socket
to detect plug-in). ....."


Maybe we should stay as it is right now or are there any problems with
the current configuration?

>  
>> We increase the cap size to at least 100uF (better more). This results
>> in a dramatically increased physical size of the capacitor. I think the
>> maximum capacity for a common 1206 ceramic cap is [hidden email].
>> (f_cutoff=50Hz @Z_headphone=32OHM and C=100uF)
>>    
>
> In the GTA03-6410 design, I see a 47 uF cap on each channel,
> following a bead.
>  

That's a question of the size, I think you can get a 0805 up to 47uF/6.3V .

>  
>> In this case we need
>> to change the headset and jack to get a separate ground for headphone
>> and microphone.
>>    
>
> That sounds very messy, as headsets with separate ground may not
> be readily available (do they even exist ?)
>
> Alas, the ~1.3 V of bias we could get with headset ground at Vmid
> doesn't seem to be enough for any microphone that would be remotely
> suitable :-(
>
>  

Yes it does, but would be the perfect solution for an external headset
(regarding bandwidth).
I could not find a way to solve the biasing problem with a common ground
for headphone and microphone. So i guess we need to stay with the dc
blocking capacitors.

>> Also in the GTA02 schematics there are 33 OHM resistors in series of the
>> headphone stereo path, they will increase the lower cutoff frequency but
>> will limit the maximum volume of the headphone.
>> Although it will increase our lower cut off frequency, I think we should
>> remove those completely. Also wolfson doesn't recommend any resistor in
>> the headphone paths.
>>    
>
> Could they be meant to offer some sort of short-circuit protection
> during jack insertion and when pressing HOLD ?
>
>  

Well I'm not completely sure about that:

The output resistance of the audio amp is really small so if you now put
a high frequent signal on the audio lines (to communicate with the
calypso) your signal will decrease pretty much.
These resistor will increase the resistance in the signal path and
improve this situation a little bit.

That's just  what i think, so I might be completely wrong!!


>  
>> Did i forgot anything else, maybe there are some problems which I'm not
>> aware of?
>>    
>
> I have some more:
>
> - no common mode choke in the stereo path (B4102). That's a component
>   change, so it may be too complicated for gta02-core, but we can at
>   least earmark it. (ECN0020)
>  

Do yo know how much it will decrease the channel separation 10, 20 or 60 dB?


> - there's a fancy new EMI-hardened microphone that comes in a square
>   package instead of the round one. I'm not sure which one we'll get
>   from Openmoko. The old one would be a little more convenient,
>   since it doesn't require case-modding. (ECN0021)
>  

Do we have any data about that microphone, e.g. part number, vendor etc.

> - add beads to keep the RF out (ECN0018)
>
> - I don't know if we'll still need to stabilize MICBIAS, aka apply
>   the buzz fix, when all this is done. (ECN0019)
>  

I do not have a lot of information what the cause of this problem
was/is. I think it would be better to find and solve the source of the
problem.

> I hope that's all the critters we have on the audio side :)
>
> - Werner
>
>  


_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware
Werner Almesberger

Re: [gta02-core] Audio rework

Reply Threaded More More options
Print post
Permalink
Rene Harder wrote:
> We keep the individual ECNs, in this way it's easier to have an overview
> of the changes.
> In the ECNs we shortly describe the reason/problem and refer to the ECN
> with the name "global audio rework".
> How does that sound?

Sounds great.

> Maybe we should stay as it is right now or are there any problems with
> the current configuration?

As far as I know, there are no unresolved problems with the jack
insertion detection logic.

> I could not find a way to solve the biasing problem with a common ground
> for headphone and microphone. So i guess we need to stay with the dc
> blocking capacitors.

So it seems :-(

> These resistor will increase the resistance in the signal path and
> improve this situation a little bit.

Ah yes, that would make even more sense.

> Do yo know how much it will decrease the channel separation 10, 20 or 60 dB?

That's too deep in analog land for me to know, sorry :)

> Do we have any data about that microphone, e.g. part number, vendor etc.

It should be a Knowles SPM0208HE5:
http://media.digikey.com/pdf/Data Sheets/Knowles Acoustics PDFs/SPM0208HE5 Rev B.pdf

> I do not have a lot of information what the cause of this problem
> was/is. I think it would be better to find and solve the source of the
> problem.

As far as I remember, the story went something like this:

- JK4401 acts as an antenna receiving the GSM's RF we emit

- the protection diodes of U4401 rectify the RF, thus acting as an
  AM demodulator

- the demodulated AM creeps via R4408 into MICBIAS, overlaying the
  microphone signal

- signal gets amplified, etc.

I'm sure Joerg will set me straight if I missed any additional twist
in this tale :-)

- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware