Bug 78640

Summary:	artsd sometimes crashes on startup if NAS output is used
Product:	[Unmaintained] arts	Reporter:	Anonymous Coward <coward>
Component:	artsd	Assignee:	Stefan Westerfeld <stefan>
Status:	CLOSED UNMAINTAINED
Severity:	crash
Priority:	NOR
Version First Reported In:	1.2.1
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	first attemp at patch

Description Anonymous Coward 2004-03-28 21:40:53 UTC

Version:           1.2.1 (using KDE KDE 3.2.1)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7 
OS:          Linux

artsd often doesn't start up properly is NAS output method is used, it usually crashes and I have to relaunch it to succeed (sometimes several times). I tracked it down to the following description:
1. AudioIONAS::open() is called, NAS library initialized, events handling set up
2. The last call in open() is call to "AuHandleEvents(aud);", which triggers call to Arts::eventHandler()
3. eventHandler calls AudioSubSystem::the()->handleIO()
4. AudioSubSystem::handleIO(). At this point, no data are in the buffer, so it tries to fill it by calling producer->needMore(); Sometimes, producer==NULL, so it prompty crashes. If I add code to return from the function in such case, NAS will complain because it won't have audio data available, and my knowledge of NAS & aRts is not (yet) good enough to know how to handle that.

If I add "sleep(1);" call just before AuHandleEvents call from 2., it no longer crashes, so I suspect some kind of race condition in AudioSubSystem -- it doesn't expect that handleIO will be called from output's open(). Is this explanation possible? Sorry there's no patch attached, I couldn't figure out how to properly fix this...

Full-duplex is not set, I force sampling rate to 44kHz/16bits (otherwise arts would pick 11kHz, I didn't investigate why).

Comment 1 Anonymous Coward 2004-03-29 13:05:24 UTC

Created attachment 5458 [details]
first attemp at patch

I'm now (after upgrade of kernel to 2.4.25) always getting the crash,
regardless of sleep() call. The real problem seems to be that
AudioSubSystem::check() was called with producer==NULL. Attached patch fixes
the bug by delaying AuHandleEvents call (which triggers handleIO call) in
AudioIONAS class. It's done by setting up a timer that will call AuHandleEvents
as soon as AudioSubSystem::running() returns true -- i.e. when it is safe to
call handleIO. The timer will shut down itself immediately afterwards.

There's a problem, though: with this patch applied, audio will be skipping and
sound unusable unless the buffer is very small (like 4 fragments of 1024
bytes). It's the worse the larger the buffer is. Any idea what could be causing
this? I must be missing something important about arts here because the patch
looks harmless to me...

Comment 2 Matt Rogers 2008-11-19 23:37:40 UTC

Arts is no longer developed and has been unmaintained for quite some time - more than 2 years. With phonon as the replacement for arts in KDE4, we're closing out all the arts bugs in Bugzilla since there is no chance of them being fixed.

Thanks