All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Wagner <will_wagner@carallon.com>
To: alsa-devel@alsa-project.org
Subject: error using aplay
Date: Fri, 02 May 2008 17:42:20 +0100	[thread overview]
Message-ID: <481B446C.20800@carallon.com> (raw)

I have cross compiled alsa-lib & alsa-utils for my arm platform. All 
appears to be working as speaker_test works fine (and have had the 
kernel sound driver working previously).

However when I try to play a wav file with aplay it fails. This is 
because in set_params(), after initialising the hardware (which happens 
with no errors), it then tries to read back the period_size with the call:

	snd_pcm_hw_params_get_period_size(params, &chunk_size, 0);

Which for the file I am playing should return 2048 but instead returns 
zero. After that it reallocs the buffer to zero size and exits. To try 
to work out what's going wrong I have been debugging this and inspecting 
params get the following:

(gdb) p *params
$21 = {flags = 0, masks = {{bits = {8, 0, 0, 0, 0, 0, 0, 0}}, {bits = 
{4, 0,
         0, 0, 0, 0, 0, 0}}, {bits = {1, 0, 0, 0, 0, 0, 0, 0}}}, mres =
{{
       bits = {0, 0, 0, 0, 0, 0, 0, 0}}, {bits = {0, 0, 0, 0, 0, 0, 0,
0}}, {
       bits = {0, 0, 0, 0, 0, 0, 0, 0}}, {bits = {0, 0, 0, 0, 0, 0, 0,
0}}, {
       bits = {0, 0, 0, 0, 0, 0, 0, 0}}}, intervals = {{min = 16, max =
16,
       openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 32, max
= 32,
       openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 2, max =
2,
       openmin = 0, openmax = 0, integer = 1, empty = 0}, {min = 22050,
       max = 22050, openmin = 0, openmax = 0, integer = 1, empty = 0}, {
       min = 92879, max = 92880, openmin = 1, openmax = 1, integer = 0,
       empty = 0}, {min = 2048, max = 2048, openmin = 0, openmax = 0,
       integer = 1, empty = 0}, {min = 8192, max = 8192, openmin = 0,
       openmax = 0, integer = 1, empty = 0}, {min = 5, max = 5, openmin =
0,
       openmax = 0, integer = 1, empty = 0}, {min = 464399, max = 464400,
       openmin = 1, openmax = 1, integer = 0, empty = 0}, {min = 10240,
       max = 10240, openmin = 0, openmax = 0, integer = 1, empty = 0}, {
       min = 40960, max = 40960, openmin = 0, openmax = 0, integer = 1,
       empty = 0}, {min = 10000, max = 10000, openmin = 0, openmax = 0,
       integer = 1, empty = 0}}, ires = {{min = 0, max = 0, openmin = 0,
       openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin =
0,
       openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin =
0,
       openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin =
0,
       openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin =
0,
       openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin =
0,
       openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin =
0,
       openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin =
0,
       openmax = 0, integer = 0, empty = 0}, {min = 0, max = 0, openmin =
0,
       openmax = 0, integer = 0, empty = 0}}, rmask = 0, cmask = 1048327,
   info = 65795, msbits = 16, rate_num = 22050, rate_den = 1, fifo_size =
0,
   reserved = '\0' <repeats 63 times>}


My reading of this is that period_size is correct at 2048, however 
openmin is 0 (dont' know what openmin is all about). So inspecting the 
code I thought this should all work. However it appears that there is 
some magic going on with functions being redirected as a backtrace shows:

(gdb) bt
#0  __snd_pcm_hw_params_get_period_size (params=0xbef44700,
val=0xbef44674,
     dir=0x2166c) at pcm.c:4263
#1  0x4006f1c8 in __old_snd_pcm_hw_params_get_period_size
(params=0xbef44700,
     dir=0x2166c) at pcm.c:6822
#2  0x0000eda0 in set_params () at aplay.c:983
#3  0x00014004 in playback_go (fd=4, loaded=0, count=171008, rtype=2,
     name=0xbef44de7 "/sdcard/sounds/tada.wav") at aplay.c:1950
#4  0x000147b8 in playback (name=0xbef44de7 "/sdcard/sounds/tada.wav")
     at aplay.c:2042
#5  0x0000c8c4 in main (argc=3, argv=0xbef44ce4) at aplay.c:615

It seems the call is somehow being redirected through 
__old_snd_pcm_hw_params_get_period_size and the implementation of this 
means that I end up returning openmin instead of min for period_size.

Can someone explain what is going on here? Why am I being redirected 
through this old function? Is it correct that I should be reading 
openmin here?

Any help much appreciated.

Will.



-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner@carallon.com
Senior Project Engineer                  Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

             reply	other threads:[~2008-05-02 16:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 16:42 Will Wagner [this message]
2008-05-02 17:57 ` error using aplay Sean McNamara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=481B446C.20800@carallon.com \
    --to=will_wagner@carallon.com \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.