From: noreply@alsa-project.org
To: alsa-devel@alsa-project.org
Subject: [ALSA - lib 0000116]: alsalib raises assertion
Date: Wed, 9 Jun 2004 20:04:08 +0200 [thread overview]
Message-ID: <d4c84f4bb208eb975667c94b853799ee@bugtrack.alsa-project.org> (raw)
A BUGNOTE has been added to this bug.
======================================================================
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000116
======================================================================
Reported By: Benjamin Otte
Assigned To: perex
======================================================================
Project: ALSA - lib
Bug ID: 116
Category: pcm - digital audio
Reproducibility: always
Severity: crash
Priority: normal
Status: assigned
======================================================================
Date Submitted: 03-04-2004 15:30 CET
Last Modified: 06-09-2004 20:04 CEST
======================================================================
Summary: alsalib raises assertion
Description:
I'm reproducing this from
http://bugzilla.gnome.org/show_bug.cgi?id=134007
I'm not able to reproduce this myself as I don't have a broken soundcard.
You might want to contact the reporter of the Gnome bug.
======================================================================
----------------------------------------------------------------------
perex - 03-05-2004 12:43 CET
----------------------------------------------------------------------
It seems like a complicated bug to me. Can you determine the used
hardware?
Perhaps, the user should communicate with us using this bug-tracking
system.
I need to know the hardware and configuration which is passed to
snd_pcm_hw_params() function (see snd_pcm_dump() and other functions which
can
print the actual configuration).
Also, you may use the snd-dummy driver to emulate any kind of hardware to
catch this sort of bugs (see alsa-kernel/drivers/dummy.c).
Also, 1.0.3 code contains some fixes regarding the sample rate
conversions,
so this bug might be already fixed.
----------------------------------------------------------------------
tiwai - 03-05-2004 19:44 CET
----------------------------------------------------------------------
does it happen with 1.0.3?
----------------------------------------------------------------------
perex - 03-23-2004 15:52 CET
----------------------------------------------------------------------
No direct contact with original reporter.
----------------------------------------------------------------------
joshuadf - 04-16-2004 04:24 CEST
----------------------------------------------------------------------
Reminder sent to perex
I can reproduce this Bug 000116 with Fedora Core 2test2, alsa-lib-1.0.3a-1
RPM. I was referred here by Colin Walters:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119958
This is using the builtin sound on an ASUS A7N266-VM/AA,
nvidia nforce chipset, standard snd_intel8x0 driver. (I'm not using the
funky nforce surround-sound features.)
I'm using gstreamer-0.8.0-4.
$ gst-launch filesrc location=music.mp3 ! mad ! alsasink
RUNNING pipeline ...
gst-launch-0.8: pcm_plug.c:882: snd_pcm_plug_hw_params: Assertion `err >=
0' failed.
Aborted
$
----------------------------------------------------------------------
Benjamin Otte - 04-19-2004 13:06 CEST
----------------------------------------------------------------------
I guess this should be reopened when someone can still reproduce it :)
----------------------------------------------------------------------
perex - 04-19-2004 15:27 CEST
----------------------------------------------------------------------
Ok, apply plug-hw-param.patch . It removes asserts, but does not solve
bug.
If it's error (the passed hardware parameters should be accepted), please,
send me
output from 'snd_pcm_dump()' for the failing parameters to reproduce bug
here. Thanks.
----------------------------------------------------------------------
noaq - 04-19-2004 21:29 CEST
----------------------------------------------------------------------
I also see this problem. This is my hardware, according to /sbin/lspci
-vvv
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
Subsystem: Asustek Computer, Inc. A7V8X Motherboard (Realtek
ALC650 codec)
I'm not entirely sure about how to determine what version of the alsa
driver that is included in the redhat development kernel that I run, but
the alsa-utils package is version 1.0.3 and I suppose that the in-kernel
code is very close to the canonical kernel.org kernel. When trying the
command
"gst-launch-0.8 filesrc location="/usr/share/sounds/startup3.wav" !
wavparse ! alsasink"
i get a back-trace very similiar to the one above.
----------------------------------------------------------------------
sxpert - 04-20-2004 00:30 CEST
----------------------------------------------------------------------
I have this bug using the following config
alsa from gentoo 2.6.5-gentoo-r1 kernel
alsalib from gentoo 1.0.3b-r2
using snd-usb-audio driver (Creative Sound Blaster MP3+ usb)
----------------------------------------------------------------------
noaq - 04-25-2004 12:03 CEST
----------------------------------------------------------------------
I'm not entirely sure about what you mean, but I have recompiled alsa-lib
with the patch above and modified the alsa gstreamer plugin to print the
return value from
snd_pcm_hw_params. It is -22.
I have also added the following after the failing call:
snd_output_t *debug_out;
snd_output_stdio_open(&debug_out, "/tmp/alsa-debug.out", "a");
snd_pcm_dump(this->handle, debug_out);
and the resulting contents of /tmp/alsa-debug.out is this:
Plug PCM: Hardware PCM card 0 'VIA 8235' device 0 subdevice 0
Is there anything else that I can do to help?
----------------------------------------------------------------------
perex - 04-25-2004 12:09 CEST
----------------------------------------------------------------------
Thanks. We are close. Please, use snd_pcm_hw_params_dump(hw_params, out)
call before snd_pcm_hw_params() call in gstreamer code. I need to know
the asking configuration.
----------------------------------------------------------------------
noaq - 04-25-2004 12:15 CEST
----------------------------------------------------------------------
snd_pcm_hw_params_dump() outputs the following:
ACCESS: MMAP_INTERLEAVED
FORMAT: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE
S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW
A_LAW IMA_ADPCM S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE
U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
SUBFORMAT: STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: (11999 49349398)
PERIOD_TIME: (166 682667)
PERIOD_SIZE: 8192
PERIOD_BYTES: [4096 655360000]
PERIODS: 2
BUFFER_TIME: (331 1365448)
BUFFER_SIZE: 16384
BUFFER_BYTES: [8192 1310720000]
TICK_TIME: 1000
----------------------------------------------------------------------
Benjamin Otte - 06-09-2004 20:04 CEST
----------------------------------------------------------------------
Attached is a .c file to reproduce the bug.
Compile with "gcc -ggdb3 `pkg-config --libs --cflags alsa` test.c -o test"
and run with "./test <device>" where "./test plughw:0" fails while "./test
hw:0" succeeds when you use an nForce2 or similar.
The problem is related to how the plug device has a dependency between
rate conversions and buffer sizes and the fact that the autodetection of
correct matches is pretty weak, because rate conversions don't check for
valid buffer sizes.
I'll attached some outputs of hw params while refining that show the issue
pretty well:
==> bt:
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000000
snd_pcm_plug_hw_refine_schange (pcm=0x80d47e0, params=0xbfffe9d8,
sparams=0xbfffe630) at pcm_plug.c:653
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000001
0x405452d1 in snd_pcm_plug_hw_params (pcm=0x80d47e0,
params=0xbfffe9d8) at pcm_plug.c:882
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000002
0x4052e0d0 in sndrv_pcm_hw_params (pcm=0x80d47e0, params=0xbfffe9d8)
at pcm_params.c:2260
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000003
0x4051f80d in snd_pcm_hw_params (pcm=0x80d47e0, params=0xbfffe9d8) at
pcm.c:784
==> params:
ACCESS: MMAP_INTERLEAVED
FORMAT: S8
SUBFORMAT: STD
SAMPLE_BITS: 8
FRAME_BITS: 8
CHANNELS: 1
RATE: [4000 4000]
PERIOD_TIME: (166 2048000]
PERIOD_SIZE: 8192
PERIOD_BYTES: 8192
PERIODS: 2
BUFFER_TIME: (331 4096000]
BUFFER_SIZE: 16384
BUFFER_BYTES: 16384
TICK_TIME: 1000
U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE
U18_3BE
SUBFORMAT: STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: [4000 4294967295)
PERIOD_TIME: (62 2048000]
PERIOD_SIZE: (0 4294967295)
PERIOD_BYTES: (0 4294967295)
PERIODS: (0 4294967295]
BUFFER_TIME: [1 4294967295]
BUFFER_SIZE: [1 4294967294]
BUFFER_BYTES: [1 4294967295]
TICK_TIME: 1000
==> bt:
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000000
snd_pcm_plug_hw_refine_schange (pcm=0x80dc9d0, params=0xbfffe9c8,
sparams=0xbfffe620) at pcm_plug.c:736
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000001
0x405452d1 in snd_pcm_plug_hw_params (pcm=0x80dc9d0,
params=0xbfffe9c8) at pcm_plug.c:882
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000002
0x4052e0d0 in sndrv_pcm_hw_params (pcm=0x80dc9d0, params=0xbfffe9c8)
at pcm_params.c:2260
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000003
0x4051f80d in snd_pcm_hw_params (pcm=0x80dc9d0, params=0xbfffe9c8) at
pcm.c:784
==> params:
ACCESS: MMAP_INTERLEAVED
FORMAT: S8
SUBFORMAT: STD
SAMPLE_BITS: 8
FRAME_BITS: 8
CHANNELS: 1
RATE: [4000 4000]
PERIOD_TIME: (166 2048000]
PERIOD_SIZE: 8192
PERIOD_BYTES: 8192
PERIODS: 2
BUFFER_TIME: (331 4096000]
BUFFER_SIZE: 16384
BUFFER_BYTES: 16384
TICK_TIME: 1000
U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE
U18_3BE
SUBFORMAT: STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: [4000 4294967295)
PERIOD_TIME: (62 2048000]
PERIOD_SIZE: (0 4294967295)
PERIOD_BYTES: (0 4294967295)
PERIODS: (0 4294967295]
BUFFER_TIME: [1 4294967295]
BUFFER_SIZE: [1 4294967294]
BUFFER_BYTES: [1 4294967295]
TICK_TIME: 1000
==> sparams:
ACCESS: MMAP_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 8000
PERIOD_TIME: [1000 2048000]
PERIOD_SIZE: [8 16384]
PERIOD_BYTES: [32 65536]
PERIODS: [1 1024]
BUFFER_TIME: [1000 2048000]
BUFFER_SIZE: [8 16384]
BUFFER_BYTES: [32 65536]
TICK_TIME: 1000
3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
SUBFORMAT: STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: [4000 4294967295)
PERIOD_TIME: (62 2048000]
PERIOD_SIZE: (0 4294967295)
PERIOD_BYTES: (0 4294967295)
PERIODS: (0 4294967295]
BUFFER_TIME: [1 4294967295]
BUFFER_SIZE: [1 4294967294]
BUFFER_BYTES: [1 4294967295]
TICK_TIME: 1000
Note how rate is 4000 vs 8000 while buffer size is 16384 vs 16384 but it
then requests 32768 for the rate conversion which fails.
The code should have picked a rate of 8000 so no rate conversion is
necessary.
GStreamer works around this now, so it's not an issue for us anymore.
Bug History
Date Modified Username Field Change
======================================================================
03-04-04 15:30 Benjamin Otte New Bug
03-05-04 11:01 perex Assigned To => perex
03-05-04 11:01 perex Status new => assigned
03-05-04 12:43 perex Bugnote Added: 0000498
03-05-04 12:43 perex Category hw specific configuration
=> pcm - digital audio
03-05-04 19:44 tiwai Bugnote Added: 0000512
03-23-04 15:52 perex Bugnote Added: 0000660
03-23-04 15:52 perex Resolution open => suspended
03-23-04 15:52 perex Status assigned => resolved
04-16-04 04:11 joshuadf Bug Monitored: joshuadf
04-16-04 04:24 joshuadf Bugnote Added: 0000826
04-19-04 13:06 Benjamin Otte Bugnote Added: 0000854
04-19-04 13:06 Benjamin Otte Resolution suspended => reopened
04-19-04 13:06 Benjamin Otte Status resolved => feedback
04-19-04 15:09 perex Status feedback => assigned
04-19-04 15:26 perex File Added: plug-hw-param.patch
04-19-04 15:27 perex Bugnote Added: 0000856
04-19-04 21:29 noaq Bugnote Added: 0000864
04-20-04 00:30 sxpert Bugnote Added: 0000868
04-23-04 00:11 benw Bug Monitored: benw
04-25-04 12:03 noaq Bugnote Added: 0000938
04-25-04 12:09 perex Bugnote Added: 0000939
04-25-04 12:15 noaq Bugnote Added: 0000940
06-09-04 20:04 Benjamin Otte Bugnote Added: 0001297
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
next reply other threads:[~2004-06-09 18:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-09 18:04 noreply [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-01-13 16:14 [ALSA - lib 0000116]: alsalib raises assertion bugtrack
2005-02-14 18:34 bugtrack
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=d4c84f4bb208eb975667c94b853799ee@bugtrack.alsa-project.org \
--to=noreply@alsa-project.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox