On 2009-12-17 at 10:08:49 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > Ingo Weinhold <ingo_weinhold@xxxxxx> wrote: > > On 2009-12-16 at 22:03:14 [+0100], Fredrik Holmqvist > > <fredrik.holmqvist@xxxxxxxxx> wrote: > > > 2009/12/16 Ingo Weinhold <ingo_weinhold@xxxxxx>: > > > > I've added a work-around for this situation in r34684. Please > > > > give it a > > > > whirl. > > > It hang hard the moment mediaplayer tried to start playing, showing > > > the beginnings of KDL in something about Audio Control.. > > I have a very hard time imagining how my change could bring this > > about. > > Particularly since the new code I've introduced is executed quite a > > bit > > earlier than (and independently of) MediaPlayer. You haven't by any > > chance > > updated the driver in a live system? To be sure that it's not some > > build > > issue, can you please remove all generated object files for the driver > > and > > rebuilt it. > > The media add-on, mixer, and HDA driver are already at work once the > media_server is running - ie. it can't be caused by any of those > components as they shouldn't care whether they are serving empty buffers > or not. > I would guess it could be related to bug #5119. Yep, given that #5145 reports such a panic in the "Audio Mixer control" thread this sounds very likely. > FWIW I've updated the driver and media node to its latest version, and > it works fine here (although I still have occasional hickups). Same here. I've tracked the audio skips a bit further and the guilty party definitely sits upstream of the audio mixer, since the buffers already arrive late there. This can be easily reproduced on my machine for instance by running a -j8 Haiku image build. The buffers immediately start arriving 10 or more ms late. Due to the generously estimated latencies the skips only happen beyond 50 ms lateness. I wasn't able to test with the latest revision yet. The recent libmedia and mp3 reader changes might already have improved the situation. CU, Ingo