[asterisk-dev] Changing channel writeformat in ast_openstream_full

Mihai Balea mihai at hates.ms
Thu Jun 28 12:48:04 CDT 2007

On Jun 28, 2007, at 12:33 PM, Steven Critchfield wrote:

> The idea is that you let the codecs worry about the translations, but
> they need to know what type of audio is coming at it to set up the
> translations.

Wouldn't this information be encoded in the frame subclass?
The way I understand it, channel->writeformat is the format that  
comes out of the channel and gets to the wire...

I'm not very familiar with this code so I wouldn't mind being told  
that I am totally wrong on this...:)

> It makes sense this way as we are reusing code that already is being
> used to convert audio as it traverses from one endpoint to another
> regardless of what the endpoints are.
> I'm not certain what obvious nasty results you are experiencing. Could
> these nasty results be related to the channel type you are using? I  
> know
> we run through these same codec changes several thousand times a  
> day on
> our machines, but they are all using ZAP channels and therefore the  
> end
> write function will always be the same codec. Maybe this keeps me from
> seeing the nasty results you are.

The results I'm seeing appear to be a codec trying to decode the  
wrong type of data, i.e. ulaw decoding gsm data.  It sounds pretty  
much like static.

Anyways, I managed to fix this issue in app-conference by making sure  
that, for each frame, the channel is set to the corresponding format.  
I was just wondering if this is the best way to do it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2411 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070628/fc55f93e/attachment.bin 

More information about the asterisk-dev mailing list