On Wed, Jul 28, 2010 at 9:55 AM, Adam Rosenberg adam@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%C2%A0-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%C2%A0). What about self-identifying devices?? Which is perhaps what gstreamer and facilities like http://live.gnome.org/GObjectIntrospection%C2%A0%C2%A0help 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