Please help to clarify when %Nxxxx settings got reset

[Al Johnson]

On Thursday 08 January 2009, Dieter Spaar wrote:
> Hello Al,
>
> > Is this something that a volunteer who's signed the NDA would be able to
> > look into? If we're lucky here might be something in the small bit of GSM
> > source OM do have access to.
>
> The actual task of modifying the audio stream is done inside the DSP.
> You will
> find in the sources that the setting is passed through several layers
> before it
> finally ends in the DSP. The DSP has its code in ROM, there is no source
> code. So you first have to read out the ROM code, disassemble it, apply
> several binary-only patches which fix bug and enhance the ROM code
> and finally try to understand quite a lot of highly optimized DSP code ;-)

It always seems so much simpler from the outside ;-) It may also be the reason 
there's no command to query the current settings.

> I really don't think that this effort is necessary for the "AT%N" settings,
> but maybe I don't understand the problem: The "AT%N" settings are
> relevant for a call. A call has to be accepted or initiated, so why not
> just set the "AT%N" settings before doing that ? If the "AT%N" settings
> don't change during a call, this should be fine and sending those setting
> every time should not really care.

The problem is that we don't know that the settings won't change during a 
call. For me setting it once works for all subsequent calls, but for others 
it works only for the first call. For all we know there may be another subset 
of users who will have it reset _during_ the call as we have no clue why it 
gets reset.

Another problem is that we don't know whether the commands are additive or 
exclusive. For example if we enable echo suppression at 12dB then noise 
reduction at 6dB do we get both, or do we end up with noise reduction but no 
echo suppression?

> > I believe this workaround has been in the 2008.x qtopia-based phone app
> > for a while, and has been proposed (including patch) for FSO. It would be
> > good to have some information about how the various settings work, but if
> > it's not possible we'll have to work with the little we have.
>
> As I wrote, the actual work is done in the DSP. I don't think that it
> makes sense to spend lots of effort in understanding the DSP just
> because of the audio settings (it might be different for RF problems
> related to #1024). Putting together the possible audio adjustments
> and trying out how they affect the audio quality is surely less effort
> and if the audio settings are applied before a call, this should be
> good enough in my opinion.

That option doesn't sound so temping when you have to pay the phone bill ;-) 
For an objective answer it requires test equipment most of us don't have 
access to, especially as we want to avoid the influence of the telcos' signal 
processing. It also won't answer the question of what causes the reset.

 To me the source usually seems like a better place to start than reverse 
engineering. If the source really can't help us with this, which seems likely 
given your explanation above, then we'll just have to do the testing and hope 
we don't have to set things more than once per call.