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
------------------------------------------------------------------------
next 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.