[alsa-devel] using plug for sample format conversion

[Niels Mayer]

On Wed, Jul 28, 2010 at 9:55 AM, Adam Rosenberg <adam at alcorn.com> wrote:
> I am trying to use plug to play audio files that are S16_LE but my
> hardware only supports S32_LE.  It is not working.  Here is an example
> of the problem using speaker-test.  First I use S32_LE and it works as
> expected.  I then try S16_LE but it fails.  Does this mean the plug
> plugin cannot convert between these sample formats?

On a similar note, someone please explain the following behavior that occurs in
playing an S16_LE stream on an M-Audio Delta 66 (...kernel/sound/pci/ice1712).

The following mplayer invocation sends  a "bit mangled" version of the
original source stream to the outputs of the soundcard, where "66ch34"
is a dshare'd device, defined per
http://nielsmayer.com/npm/dot-asoundrc.txt .

///////  /////////  ////////  ////////  //////////
$ mplayer -quiet http://media.kcrw.com/live/kcrwlive.pls -ao alsa:device=66ch34
[...]
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, s16le, 112.0 kbit/7.94% (ratio: 14000->176400)
[...]
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
[...]
Starting playback...
///////  /////////  ////////  ////////  //////////

Playing the exact same stream using  http://space.twc.de/~stefan/gst123.php
$ gst123 -a alsa=66ch34 http://64.12.61.1:80/stream/1046
uses the correct format and so the playback sounds as intended.

And whereas mplayer has no problem talking directly to snd_hda_intel
device, e.g.:
$ mplayer -quiet http://media.kcrw.com/live/kcrwlive.pls -ao alsa:device=hw=SB

Doing the same with the delta-66 gives:

///////  /////////  ////////  ////////  //////////
[AO_ALSA] Format s16le is not supported by hardware, trying default.
[AO_ALSA] Unable to set format: Invalid argument
Failed to initialize audio driver 'alsa:device=hw=M66'
///////  /////////  ////////  ////////  //////////

So where exactly is gst123 succeeding and how is the application able
to find out form ALSA that the format isn't supported, and then
correctly goes off and uses plughw (presumably) to get the correct bit
depth/order/complement matching?

Alternately, why do different applications behave differently based on
the sound card they're talking to. Is this an mplayer bug (in not
handling/preventing ALSA failure "Unable to set format: Invalid
argument"). How is gst123 and its http://www.gstreamer.net/
infrastructure handling this, and shouldn't this capability be an
underlying part of ALSA that is automatically invoked?

In programming, those working in dynamic languages have long enjoyed
the benefits of "self-identifying data" (
http://www.cs.rice.edu/~javaplt/311/Notes/09/05.supp.html ).
What about self-identifying devices?? Which is perhaps what gstreamer
and facilities like http://live.gnome.org/GObjectIntrospection  help
enable,  the fruits of which can be automatically enjoyed by apps like
gst123 ?

Is there a Vala-based "gstreamer toolkit" ?? Seems like that would be
the easiest way to gain well-integrated, and properly introspected
access all the way down to the ALSA level. Although I guess this would
require Glib-wrappers for ALSA to help describe what's actually there,
so as to allow the framework to delegate to the appropriate ALSA level
in a data-driven fashion.

Niels
http://nielsmayer.com