[gst-devel] What is the purpose of gst audioconvert plugin

[Sean McNamara]

Hi,

On Mon, Dec 27, 2010 at 5:52 AM, Anirudh <anirudhtomer at gmail.com> wrote:
>
> So I was going thru the gst manual and I found that in an example for playing
> an ogg file they were using an audio converter after decoding the ogg format
> into raw format.
>
> the pipeline they were using is as follows:
>
> file-source | ogg-demuxer | vorbis-decoder | converter | alsa-output
>
> so my question is what is the purpose of audioconverter when I have already
> decoded it.
> I mean!!! to which format am I converting it.

The audioconvert element's purpose is to act both as a negotiator and
a sort of policeman. The negotiator part is this: the audioconvert
element is extremely flexible as to the audio formats it will accept
on either "end" of the element (the source pad and the sink pad). So
it helps two plugins potentially expecting an incompatible format to
"talk" to one another seamlessly. The policeman part is this: the
audioconvert element *makes sure* that the audio flowing from its sink
pad to its source pad is going to be converted to the format that the
source pad's client expects. It has fairly good error checking if it
is unable to do that for some reason, and it is fairly good at
performing most conversions without any loss of data (except where
data loss is inevitable, such as stereo to mono).

Unfortunately, the audioconvert element does not (that I am aware)
perform sample rate conversions. For that, you need the
`audioresample' element. Its goals and function are vaguely similar to
audioconvert, except that, rather than converting sample format
parameters such as encoding, bit depth, and number of channels,
instead it converts between sample rates. You can think of the element
chain `audioconvert ! audioresample' as being a single unit that
performs full-scope sample format negotiation and conversion for all
of the standard parameters of a PCM sample.

The reason why audioconvert is necessary in that case is that the
alsasink element (as well as many other elements) are not able to
unconditionally accept all sample formats. Here's a simple example.

Let's say you have a PCI sound card that accepts sample formats that
are 8 or 16-bits wide, signed little endian, stereo or up to 5.1
channels, and sample rates from 8000 Hz to 48000 Hz.

If your alsasink element does not specify an ALSA device string that
goes through the ALSA `plug' PCM plugin, then ALSA is incapable of
supporting sample formats that your soundcard does not natively
support in the hardware. So if you pass a 192 KHz sample of 32-bit
floats in 8.1 channel to the above stated soundcard, you will get an
error in the alsasink element.

Not to overgeneralize, but the basic point is that not all
"uncompressed" or "decoded" audio is created equal, and you can not
take for granted that any two GStreamer elements supporting
uncompressed PCM audio will necessarily be able to natively support
all possible sample formats. The solution is to use extra CPU power to
do the needed conversions with the audioconvert and audioresample
elements.

HTH,

Sean

> So if I have decoded it into raw format, I think I can directly play it.
>
> please enlighten me!!! THanks in advance
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/What-is-the-purpose-of-gst-audioconvert-plugin-tp3164871p3164871.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>