--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Michal Pasternak wrote:
> Even if -current threads are different, than Pth, same situation occured =
on
> Thomas Klausner's computer, running -current, which makes me belive, that=
 it
> might not be a threading library issue. I may be wrong at all, but this
> could be a problem with the way /dev/audio is handled in kernel.

Actually, since 1.6ZE (IIRC) I've noticed that the audio device seems
to die (or rather lock) after a while. The processes will then hang
either in aud_rd or aud_wr state. When I try to kill them I have to
wait quite a while until the processes finally die.
Neither audioplay nor audiorecord (which aren't threaded) will have
any success, they just hang like any other process. I somewhat
assume that the IRQ for the audiocard remains blocked but I don't
know how I could determine that (without fiddling with the kernel
sources - it isn't ad hoc reproducible anyway).
At first, I thought this might be a systrace issue as I use it for
mplayer and ogg123 but even an untraced application makes any
differences after that.

--=20
Christian

--qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/yljW0KQix3oyIMcRAtwEAJ4lnGVSf9KXDuvZweeYLPw3DOvsIgCcCPwR
tQqSLApmh/F1LMsCcLn4sMk=
=ye4P
-----END PGP SIGNATURE-----

--qDbXVdCdHGoSgWSk--