NetBSD Problem Report #23571

Received: (qmail 28275 invoked by uid 605); 25 Nov 2003 21:15:19 -0000
Message-Id: <20031125210829.1733.qmail@pr93.lublin.sdi.tpnet.pl>
Date: 25 Nov 2003 21:08:29 -0000
From: Michal@pr93.lublin.sdi.tpnet.pl, Pasternak@pr93.lublin.sdi.tpnet.pl
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: Michal Pasternak <dotz@irc.pl>
To: gnats-bugs@gnats.netbsd.org
Subject: devel/pth is unable to read audio device in various packages
X-Send-Pr-Version: 3.95

>Number:         23571
>Category:       kern
>Synopsis:       devel/pth is unable to read audio device in various packages
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 25 21:16:00 +0000 2003
>Closed-Date:    
>Last-Modified:  Sun Feb 26 16:23:02 +0000 2012
>Originator:     Michal Pasternak
>Release:        NetBSD 1.6.1
>Organization:
Good People With Bad Reputation
>Environment:


System: NetBSD mainframe.w.lub.pl 1.6.1 NetBSD 1.6.1 (GENERIC) #0: Tue Apr 8 12:05:52 UTC 2003 autobuild@tgm.daemon.org:/autobuild/netbsd-1-6/i386/OBJ/autobuild/netbsd-1-6/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:

	devel/pth is GNU Lightweight Threads package, working mainly as
	a replacement layer for POSIX thread.

	On NetBSD-1.6.1 at the time of writing it is unable to read
	/dev/audio . I don't know about the underlying cause, but it
	could mean it is unable to read other special files as well.
	It could also mean a bug in underlying layers (libc?)

	The problem results in unability to record sound in packages
	like audio/sweep, wip/portaudio, wip/py-fastaudio, lang/python23-pth,
	lang/python22-pth and propably many other packages.

>How-To-Repeat:

	1) install one of above packages
	2) try to record sound.

	Python's proof of concept:
	- we'll use this simple one-liner to demonstrate the bug:

		open("/dev/audio", "rb").read(10)

	- on non-pth Python (I have used 2.0.1):

	Python 2.0.1 (#1, Nov 25 2003, 21:42:48) 
	[...]
	>>> open("/dev/audio", "rb").read(10)     
	'\377\377\377\377\377\377\377\377\377\377'

		- it reads the static. Good!

	- on a Pth-enabled Python you will wait for this read _forever_

>Fix:

        Fix is _crazy_, but first let me talk for a minute.

	All GNU Pth programs that utilize Pthread simulation are in
	reality a "standard", single-thread, event-driven applications.
	GNU Pth uses re-defined blocking functions, as you can easy
	check by running:

		grep pthread_read /usr/pkg/include/pthread.h

	Substituted read function (in reality, pthread_read) is declared
	in pth_high.c .

	I have debugged this and found out, that all programs stop
	at pth_high.c:788 , in pth_wait. 

	This stop is either caused by bad event mask set in pth_high.c:785
	(and no, adding PTH_EVENT_FD_EXCEPTION didn't help at all), or - 
	pth_event has some bugs, which occur while using /dev/audio .

	The thing, that helps is... adding PTH_UNTIL_FD_WRITEABLE in
	pth_high.c at line 785 .

	And, guess what? Sweep allows me to record my freestyle raps, I can
	finally write my Python VoIP software with py-fastaudio, everyone
	is happy.

	Send patch, you say.

	Someone with bigger knowledge than mine could write up a patch 
	for this . First, you need to check if it's only /dev/audio, or
	does it hit other devices as well . Second, we need to create
	a patch, that will apply only to devices, which are handled
	in a broken (blocking) way by Pth. And no, testing by fstat(2)
	in pth_high.c if the fd is a device won't give you proper results
	(it seems it can read other "devices" without blocking)
>Release-Note:
>Audit-Trail:

From: Michal Pasternak <michal@pasternak.w.lub.pl>
To: Michal Pasternak <dotz@irc.pl>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/23571: devel/pth is unable to read audio device in various packages
Date: Tue, 25 Nov 2003 23:02:12 +0100

 In case it is needed: soundcards, on which such situation occured, are:

 # dmesg | grep audio
 audio0 at cmpci0: full duplex, mmap, independent
 # dmesg | grep cmpci
 cmpci0 at pci0 dev 14 function 0: C-Media Electronics, Inc. CMI8738/C3DX PCI
 +Audio Device (rev. 0x10)
 cmpci0: interrupting at irq 10
 audio0 at cmpci0: full duplex, mmap, independent
 opl0 at cmpci0: model OPL3: LR swapped
 mpu0 at cmpci0

 doc@mainframe:~> /sbin/dmesg|grep audio
 audio0 at eap0: full duplex, mmap, independent
 doc@mainframe:~> /sbin/dmesg | grep eap0
 eap0 at pci0 dev 11 function 0: Ensoniq AudioPCI 97 ES1373B (rev. 0x06)
 eap0: interrupting at irq 3
 eap0: TriTech unknown codec; no 3D stereo
 audio0 at eap0: full duplex, mmap, independent
 midi0 at eap0: AudioPCI MIDI UART

 Please note, that they're both full-duplex. 
 -- 
 Michal Pasternak :: http://pasternak.w.lub.pl

From: gson@gson.org (Andreas Gustafsson)
To: Michal Pasternak <michal@pasternak.w.lub.pl>
Cc: port-i386@NetBSD.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/23571: Possible bug in audio drivers - request help with debugging
Date: Tue, 25 Nov 2003 20:46:36 -0800 (PST)

 Michal Pasternak writes:
 > On NetBSD-1.6.1 at the time of writing it is unable to read /dev/audio

 Here is what I believe is happening.

 They way the NetBSD audio device has always worked is that when you
 open it, it starts out in the "recording paused" state.  It only starts
 recording once you either explicitly unpause it using something like

 	AUDIO_INITINFO(&info);
 	info.record.pause = 0;
 	int r = ioctl(fd, AUDIO_SETINFO, &info);

 or, alternatively, when you when do a read() on it.

 When accessing the audio device through a thread package, the read()
 calls will be intercepted by the thread package and the actual read()
 system call will only be invoked when select() (or poll()) indicates
 that the device file descriptor is ready for reading; until that time,
 the thread will be blocked.  Since recording is initially paused,
 there will never be any data to read, select() never indicates a
 "ready to read" condition, the real read() system call is never
 actually called, and recording never starts.

 This behavior has always struck me as odd, but I'm not entirely sure
 whether it's a bug or just the correct implementation of a confusing
 and insufficiently documented design.
 -- 
 Andreas Gustafsson, gson@gson.org

From: Lennart Augustsson <lennart@augustsson.net>
To: Andreas Gustafsson <gson@gson.org>
Cc: Michal Pasternak <michal@pasternak.w.lub.pl>, port-i386@NetBSD.org,
  gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/23571: Possible bug in audio drivers - request help with
 debugging
Date: Wed, 26 Nov 2003 10:10:06 +0100

 Andreas Gustafsson wrote:
 > This behavior has always struck me as odd, but I'm not entirely sure
 > whether it's a bug or just the correct implementation of a confusing
 > and insufficiently documented design.
 It's probably there by design, but I think it's not a feature anyone
 uses, so I don't think it would be missed.

 	-- Lennart



From: Michal Pasternak <michal@pasternak.w.lub.pl>
To: Andreas Gustafsson <gson@gson.org>
Cc: Michal Pasternak <michal@pasternak.w.lub.pl>, port-i386@NetBSD.org,
  gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/23571: Possible bug in audio drivers - request help with debugging
Date: Tue, 2 Dec 2003 06:18:24 +0100

 Andreas Gustafsson [Tue, Nov 25, 2003 at 08:46:36PM -0800]:
 > This behavior has always struck me as odd, but I'm not entirely sure
 > whether it's a bug or just the correct implementation of a confusing
 > and insufficiently documented design.

 I've read audio(4) some more, I've read sys/ sources. This is neither a bug,
 nor a non-documented feature, it seems standard... but it's quite itchy. How
 does Linux deal with full duplex cards?

 -- 
 Michal Pasternak :: http://pasternak.w.lub.pl
Responsible-Changed-From-To: pkg-manager->kern-bug-people
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Wed, 23 Mar 2005 01:23:53 +0000
Responsible-Changed-Why:
Reading the PR, I see that
the discussion switches to the audio subsystem in the kernel.


>Unformatted:

Home	PR Database Search