[Asterisk-Users] Wildcard X100P or TDM400P?

[Rich Adamson]

> On Tue, 2005-03-08 at 13:24 -0600, Rich Adamson wrote:
> > > > > TDM400P with FXO daughter card includes 1 hour of Digium support. It is
> > > > > supposed to support other line types. If you have trouble, it is likely
> > > > > you will get direct support from Digium and from the community here. 
> > > > 
> > > > It should be noted that several people including myself are having voicemail
> > > > volume problems with the TDM400P (is anyone having it with the X100P?) which
> > > > for us makes the card unusable for what was intended (a basic home PBX/answering
> > > > machine).
> > > > 
> > > > This is documented in bug #2023:
> > > > http://bugs.digium.com/bug_view_page.php?bug_id=0002023
> > > > 
> > > > You'll also notice that it has been dormant for quite some time.
> > > 
> > > Voicemail volume is not related to the card you use. If it was related
> > > to the card used, you wouldn't have the separation needed to make all
> > > the interfaces work.
> > > 
> > > Voicemail volume is usually complained about by people not using
> > > standard wav format. It is due to the volume of wav files being
> > > manipulated at write time where as all other formats are as they come
> > > off of the line.  
> > 
> > Steve, help me understand exactly what you said above. Having problems
> > with "to the card you use" and "related to the card used".
> 
> By the time any audio makes it to voicemail, it has been "normalized"
> into ast_frames. The source of audio is not relevant to the voicemail
> app.  
> 
> > Also, please clearify "not using standard wav format". Does that truly
> > mean recording voicemail messages in gsm format is the cause for the
> > additional 10db of loss measured and noted in bug 2023?
> 
> I don't know or care how you are measuring a 10db loss. I know for a
> fact that in format_wav.c there is a section of code that effectively
> doubles the volume as it is saving and removes the doubling on playback.
> No other audio format is given the same treatment.
> 
> > If that's the case, then why has bug 2023 been lurking without any such
> > comments for many many months?
> 
> If it is lurking for 10 months it is because no one cares to read it. I
> promise you I don't look at any bug unless it is mentioned on a list as
> is pertaining to code I am running. I have so little time now, I don't
> go looking for needles in haystacks that I don't need.

The only reason for questioning the above is that Mark (and several others)
have contributed various comments to bug 2022 and 2023, but at no time
have any of them ever mentioned comments relative to wav vs other file 
formats, and effectively have left the bug unresolved.

Rich