[alsa-devel] using plug for sample format conversion
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, };
Can you tell me how to configure and install the latest ALSA and whether the snd_pcm_hardware is correct?
Thanks, Adam
Adam Rosenberg Software Engineer
Alcorn McBride Inc. 3300 South Hiawassee Building 105 Orlando, FL 32835
(407) 296 - 5800 ext. 5490
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...
I have a few other things going on at the office but here is a month late status to close out this thread:
I see now that it fails with S16_LE because of this:
ACCESS = 0000000000000007 -> 0000000000000000
when it works using S32_LE is shows this:
ACCESS = 0000000000000008 -> 0000000000000008
because of this issue I decided to implement S16_LE support in my driver directly. This turned out to just be a workaround though as the real problem seems to be in the organization of the actual driver. I will send a separate message to alsa-devel about this.
Thanks, Adam
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
participants (3)
-
Adam Rosenberg
-
Niels Mayer
-
Raymond Yau