[asterisk-dev] Changing channel writeformat in ast_openstream_full

[Steven Critchfield]

On Wed, 2007-06-27 at 11:56 -0400, Mihai Balea wrote:
> Hi all,
> 
> I've noticed that ast_openstream_full(), in file.c, changes the  
> channel write format to conform to the format of the file being opened.
> I am wondering why this is so, since the way I see it, file  
> operations should just provide a data stream to be used by other  
> layers and modules.
> 
> More to the point, this behavior was causing some issues in  
> app_conference, when sound files of different types where queued for  
> playback.  When playing a file encoded in gsm, if a second file,  
> encoded in ulaw, is queued, then ast_openstream_full will change the  
> channel write format in midflight with all the obviously nasty results.
> 
> Can somebody shed some light into this?

Don't take my comments as authoritative. My memory of that section of
code is also dated.

The code you traverse to get a file played to a channel is

--filesystem read
format_* to actually read the bits out of a formatted file.
ast_openstream_full to hand the audio up to the channel
codec_* to translate it

Or something like that. 

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. 

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.
-- 
Steven Critchfield <critch at basesys.com>