2010/7/29 Adam Rosenberg adam@alcorn.com

...

...

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?

Thanks, Adam

Please use latest version of speaker-test and alsa-lib.

and post struct snd_pcm_hardware of you driver

I am using the latest release of uClinux for Blackfin BF537 and do not know how to configure and install the latest version of alsa-lib and alsa-utils. I am starting to understand how struct snd_pcm_hardware is used by the ALSA PCM code but you are correct to assume I may have something wrong. Here is the struct:

static struct snd_pcm_hardware ourCS42448PcmHw = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER ), .formats = SNDRV_PCM_FMTBIT_S32_LE, .rates = SNDRV_PCM_RATE_48000, .rate_min = 48000, .rate_max = 48000, .buffer_bytes_max = 32768, .channels_min = 1, .channels_max = 2, .period_bytes_max = 32768, .periods_min = 1, .period_bytes_min = 8, .periods_max = 4096, };

Unable to set hw params for playback: Invalid argument Setting of hwparams failed: Invalid argument

This will tell you which argument is invalid

export LIB_LIBASOUND_DEBUG=1 speaker-test -l 1 -r 48000 -c 2 -F S16_LE -Dplughw:0,0,0

If the above still cannot help you find out the problem

you will need to enable RULES_DEBUG in core/pcm_native.c and check the system log to find out how those hw parameters are refined

if you cannot use latest version of speaker-test , read the history of speaker-test

http://git.alsa-project.org/?p=alsa-utils.git;a=history;f=speaker-test/speak...

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