LPC cowfficient freeze

           In recent past there was a suggestion thrown to me to freeze the
LPC
     coefficient to save computation cycles and the "rational" is speech
     is stationary in nature! 
     
     The application is a vocoder.

    I was shocked and still remain shocked but if you guys have an
opinion
    how to deal with this suggestion. If the filter remains constant, can
    we still find and calculate all possible excitation vector to best
    fit  and   then eventually reproduce the original signal ? Is it at
all worth
    giving a try?   

>           In recent past there was a suggestion thrown to me to freeze
the
>LPC
>     coefficient to save computation cycles and the "rational" is speech
>     is stationary in nature! 
>     
>     The application is a vocoder.
>
>    I was shocked and still remain shocked but if you guys have an
>opinion
>    how to deal with this suggestion. If the filter remains constant,
can
>    we still find and calculate all possible excitation vector to best
>    fit  and   then eventually reproduce the original signal ? Is it at
>all worth
>    giving a try?   
>
Any opinion on another suggestion that open loop pitch can be inferred
from LSFs becuase the lowest LSF gives the fundamental frequeny and hence
the pitch.

pal.debabrata123 wrote:

>            In recent past there was a suggestion thrown to me to freeze the
> LPC
>      coefficient to save computation cycles and the "rational" is speech
>      is stationary in nature! 
> 
>      The application is a vocoder.

The typical forward adaptive 10th order LPC computing demands are 
negligible compared to the pitch or the codebook search. There is no point.


>     I was shocked and still remain shocked but if you guys have an
> opinion
>     how to deal with this suggestion. If the filter remains constant, can
>     we still find and calculate all possible excitation vector to best
>     fit  and   then eventually reproduce the original signal ? Is it at
> all worth
>     giving a try? 

If you freeze the LPC at some "average" value, the prediction gain will 
  suffer somewhat 6dB loss, with the corresponding decrease in SNR. The 
perceived loss of quality will be even higher then that.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

pal.debabrata123 wrote:


> 
> Any opinion on another suggestion that open loop pitch can be inferred
> from LSFs becuase the lowest LSF gives the fundamental frequeny and hence
> the pitch.

Sheer nonsense. There is no relation.
Extra knowledge only hurts the idiots.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

>
>
>pal.debabrata123 wrote:
>
>>            In recent past there was a suggestion thrown to me to freeze
the
>> LPC
>>      coefficient to save computation cycles and the "rational" is
speech
>>      is stationary in nature! 
>> 
>>      The application is a vocoder.
>
>The typical forward adaptive 10th order LPC computing demands are 
>negligible compared to the pitch or the codebook search. There is no
point.
>
>
>>     I was shocked and still remain shocked but if you guys have an
>> opinion
>>     how to deal with this suggestion. If the filter remains constant,
can
>>     we still find and calculate all possible excitation vector to best
>>     fit  and   then eventually reproduce the original signal ? Is it
at
>> all worth
>>     giving a try? 
>
>If you freeze the LPC at some "average" value, the prediction gain will 
>  suffer somewhat 6dB loss, with the corresponding decrease in SNR. The 
>perceived loss of quality will be even higher then that.
>
>
>Vladimir Vassilevsky
>DSP and Mixed Signal Design Consultant
>http://www.abvolt.com
>
Thanks Vladimir , if can remember , almost one year back I came to
Comp.Dsp for the first time to ask some basic question about g.729 and you
clarified there are g.729, g.729a etc.
we chose g.729a. For g.729a when I ported ITU-T code to a mips 32
processor it took 200 MIPS for encoding only.
After inlining basic ops it took 100 mips.
After converting all DPF to normal MIPS 32bit instruction it reduced
further.
After writing another basicops which does not care about overflow, and
using it instead the original basic ops in some selected files, it reduced
further.
After switching to AMDF for open loop pitch ,it went further down.

For encoding and decoding cycle it is taking 78 MIPS right now.

Just thought to share the info to all.

pal.debabrata123 wrote:


> we chose g.729a. For g.729a when I ported ITU-T code to a mips 32
> processor it took 200 MIPS for encoding only.
> After inlining basic ops it took 100 mips.
> After converting all DPF to normal MIPS 32bit instruction it reduced
> further.
> After writing another basicops which does not care about overflow, and
> using it instead the original basic ops in some selected files, it reduced
> further.
> After switching to AMDF for open loop pitch ,it went further down.
> For encoding and decoding cycle it is taking 78 MIPS right now.

That means you are not compliant to G.729a, and it is very likely that 
the quality of your non-standard coder is lower. What is the goal?

BTW, g.729 is quite demanding about the computation. Why did you choose 
it as the prototype?


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

>
>
>pal.debabrata123 wrote:
>
>
>> we chose g.729a. For g.729a when I ported ITU-T code to a mips 32
>> processor it took 200 MIPS for encoding only.
>> After inlining basic ops it took 100 mips.
>> After converting all DPF to normal MIPS 32bit instruction it reduced
>> further.
>> After writing another basicops which does not care about overflow, and
>> using it instead the original basic ops in some selected files, it
reduced
>> further.
>> After switching to AMDF for open loop pitch ,it went further down.
>> For encoding and decoding cycle it is taking 78 MIPS right now.
>
>That means you are not compliant to G.729a, and it is very likely that 
>the quality of your non-standard coder is lower. What is the goal?
>
>BTW, g.729 is quite demanding about the computation. Why did you choose 
>it as the prototype?
>
>
>Vladimir Vassilevsky
>DSP and Mixed Signal Design Consultant
>http://www.abvolt.com
The goal is MOS rather than exact bit compliance ( exact transmission
parameters are assumed).In fact  I wrote a VAD decision program and
thinking to use it instead of original 729ab vad decision procidure.(exact
dtx/cng paramaters are assumed).
Now the big question is MOS quality. Sage instrument does that ? Any idea
how to measure it as and when I deviate more and more from the proper
g.729?  
>

pal.debabrata123 wrote:


> Now the big question is MOS quality. Sage instrument does that ? Any idea
> how to measure it as and when I deviate more and more from the proper
> g.729?  

ITU-T P.8xx reqs define the MOS test as well as other means for the 
evaluation of the quality of the voiceband coders. Keep in mind that you 
have to test your codec not just for English but for all world common 
languages also.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Vladimir Vassilevsky <antispam_bogus@hotmail.com> writes:

> pal.debabrata123 wrote:
>
>
>> Now the big question is MOS quality. Sage instrument does that ? Any idea
>> how to measure it as and when I deviate more and more from the proper
>> g.729?
>
> ITU-T P.8xx reqs define the MOS test as well as other means for the
> evaluation of the quality of the voiceband coders. Keep in mind that
> you have to test your codec not just for English but for all world
> common languages also.

Who performs "type approval" for this codec? (Is "type approval" the
right phrase?)
-- 
%  Randy Yates                  % "Watching all the days go by...    
%% Fuquay-Varina, NC            %  Who are you and who am I?"
%%% 919-577-9882                % 'Mission (A World Record)', 
%%%% <yates@ieee.org>           % *A New World Record*, ELO
http://www.digitalsignallabs.com