Stefan Sayer wrote: > Jeremy A wrote: >> Hi, >> >> I've got a few questions and perhaps a problem or two with using codecs >> in SEMS 1.2.1 >> >> Is there any rate conversion between files stored on disk in WAV format >> and the line rate? In my case I have a 16000 Hz wav file and am using >> G711 codec. The played out sound is very slow, so even though SEMS reads >> the file as 16000 Hz (as per debug) The delivered rate assumes 8000 Hz >> so the sound is half speed. >> >> I am a bit surprised there is no rate conversion, so I would like to > sampling rate conversion is currently only done in the wb (widenband) > branch, which supports different sample rates.
Do you use libsamplerate? or some other process? > >> know if there is a flag I have to set? >> >> I am trying to use G726-32 codec for some communications. The behaviour >> is very odd >> The debug shows the call phone requesting G726_32 >> >> Content-Type: application/sdp >> P-App-Param: usr=12345 >> >> v=0 >> o=- 7373316 7373316 IN IP4 203.31.40.160 >> s=- >> c=IN IP4 203.31.40.102 >> t=0 0 >> m=audio 8020 RTP/AVP 2 101 >> a=rtpmap:2 G726-32/8000 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-15 >> a=ptime:30 >> a=sendrecv >> a=nortpproxy:yes >> >> (I'm using rtpproxy for recording which causes a minor and inaccurate >> problem from the nortpproxy line) >> >> The reply is >> >> Content-Type: application/sdp >> Content-Length: 198 >> >> v=0 >> o=sems 1219929049 1248189210 IN IP4 203.31.40.68 >> s=session >> c=IN IP4 203.31.40.68 >> t=0 0 >> m=audio 8000 RTP/AVP 2 101 >> a=rtpmap:2 G721/8000 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-15 >> >> Where it seems SEMS has substituted G721 for G726_32 ? Is this an >> error? (This shows up on wireshark as well) > it's the same codec. g726 is the newer standard. for an overview, see > e.g. wikipedia. > >> >> At this stage I get a protocol error on the phone. > that's not good. which one is it? IMO the phone should not complain. > > quick fix: swap lines 94 and 95 of core/plug-in/adpcm/adpcm.c, or > remove line 94 (but then sems won't understand G726-32) > The phone is a Linksys/CISCO SPA962. It has other problems as well, but it is relatively common. >> >> At various stages of testing I've got sound through but just as noise. >> Does SEMS require the wav file to be in the same format as the line >> format? or can it transcode? Can it rate convert when codecs are >> different. > it does transcoding. the best is to have wav files as 16 bit pcm, 8khz > sample rate. otherwise, sems needs to transcode into 16 bit pcm, and > then into the codec used in the call. My files are 16 bit PCM. The wire format is G711 > > >> >> I can work around all these problems by using G711 and 8000 Hz wav >> files, but being able to work at G726-32 would be very helpful, as would > don't use G711 for the wav files, but linear PCM 16 bit. otherwise you > loose audio quality (G711 is NOT transparent, and you'd effectively > tandem G711 and G726). > > obcious exception: precoded announcements. This is the issue. It is a precoded announcement. What is the preferred format? Do I have to change file depending on detected codec? > >> automatic rate conversion. > indeed, that would be convenient. but already for performance reasons > alone, I would resample the files offline. > > hth > Stefan How does the non-wideband system handle non 8 Khz codecs - such as GSM? This is a general question relating to precoded announcements and stored .WAV files (I assume GSM is now a standard WAV format?) _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
