Please help to clarify when %Nxxxx settings got reset
spaar at openmoko.org
Thu Jan 8 08:32:29 CET 2009
> 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.
find in the sources that the setting is passed through several layers
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 ;-)
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.
> 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.
More information about the devel