Ticket #120 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

OSS record with aoss and pulse causes pcm_pulse.c:500: pulse_hw_params: Assertion `!pcm->stream'

Reported by: lindi Owned by: ossman
Milestone: Component: alsa-plugins-pulse
Keywords: Cc:

Description

Steps to reproduce:[[BR]]
1) Get configuration files from http://lindi.iki.fi/lindi/voip/pulse-setup-1/ or see the attached tarball.
2) Place configuration files to both a client and a server computer as well as to your home directory.  Note, here "client" refers to the thin client where the pulseaudio daemon runs (X style backwards terminology).
3) aoss sox -t ossdsp -r 44100 -c 1 -w /dev/dsp rec.wav

Expected results:
3) audio is captured on thin client and sent over network to sox that saves it to rec.wav

Actual results:
3) sox dumps core and prints
E: shm.c: shm_open() failed: Function not implemented
sox: pcm_pulse.c:500: pulse_hw_params: Assertion `!pcm->stream' failed.
Aborted (core dumped)

where "shm_open() failed: Function not implemented" is printed with red color.

More info:
1) I am using Debian GNU/Linux unstable with 0.9.6-1 on server and Debian GNU/Linux stable with pulseaudio 0.9.5-5.
2) The bug occurs also if I run pulseaudio 0.9.5-5 on both server and client.
3) gdb shows the following backtrace
#2  0xb7a83b50 in __assert_fail () from /lib/libc.so.6
#3  0xb7eedf89 in pulse_hw_params (io=0x80cba60, params=0xbf8f2610) at pcm_pulse.c:500
#4  0xb7c9ab73 in snd_pcm_ioplug_hw_params (pcm=0x80cc128, params=0xbf8f2610) at pcm_ioplug.c:386
#5  0xb7c55fd0 in sndrv_pcm_hw_params (pcm=0x80cc128, params=0xbf8f2610) at pcm_params.c:2316
#6  0xb7c45477 in snd_pcm_hw_params (pcm=0x80cc128, params=0xbf8f2610) at pcm.c:824
#7  0xb7a57f40 in oss_dsp_hw_params (dsp=0x80c1700) at pcm.c:307
#8  0xb7a58392 in oss_dsp_params (dsp=0x80c1700) at pcm.c:408
#9  0xb7a59acf in lib_oss_pcm_ioctl (fd=5, cmd=3221508101) at pcm.c:933
#10 0xb7ef2c7e in ioctl (fd=5, request=3221508101) at alsa-oss.c:374

4) With a hardware watchpoint in gdb I can see that pcm->stream is modified as follows:
NULL -> !NULL at pulse_prepare (io=0x80cba60) at pcm_pulse.c:458
!NULL -> NULL at pulse_prepare (io=0x80cba60) at pcm_pulse.c:446
NULL -> !NULL at pulse_prepare (io=0x80cba60) at pcm_pulse.c:458

5) Please let me know if you are not able to reproduce the bug. I'm happy to provide more info or test different patches.

Attachments

pulse-setup-1.tar.gz (3.5 kB) - added by lindi 3 years ago.
ALSA and pulseaudio configuration files to reproduce the bug

Change History

Changed 3 years ago by lindi

ALSA and pulseaudio configuration files to reproduce the bug

Changed 3 years ago by lennart

  • owner changed from lennart to ossman
  • component changed from daemon to alsa-plugins-pulse

Changed 3 years ago by lennart

  • owner changed from ossman to lennart
  • status changed from new to assigned

Hmm, if shm_open() doesn't work for you you must have a seriously broken setup? What kernel is this? Have you setup /dev/shm properly for POSIX shm?

Yes, the ALSA plugin shouldn't hit an assert in this case. But this seems to be caused by a system misconfiguration.

Changed 3 years ago by lennart

  • owner changed from lennart to ossman
  • status changed from assigned to new

Changed 3 years ago by lindi

Aha, indeed, /dev/shm was not mounted inside the unstable chroot. I'm sorry if this caused unnecessary confusion. I mounted it and now it does not complain about shm_open() but it still dies with the same assertion failure. Also, this is stock linux-image-2.6.18-4-k7 version 2.6.18.dfsg.1-12etch2 in Debian GNU/Linux etch.

Changed 3 years ago by edgecase

This looks to me like a duplicate of bug #23

Changed 3 years ago by allquixotic

The shm error is separate from the pcm_pulse:500 error. I believe that even with a properly working shm you still get that error.

If so, this error is resolved either: (1) in the latest release of sox, or (2) in the latest HG source of alsa-plugins. See https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3470

Please test it and let me know if this fixes your problem.

Changed 3 years ago by lennart

  • status changed from new to closed
  • resolution set to fixed

I think this is https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3470 and has been fixed a while back in ALSA upstream.

Note: See TracTickets for help on using tickets.