Browse haiku: This Month's Archive • Main Archive Page • Related posts • Previous by Date • Next by Date

[openbeos] Re: mov reader

From: Marcus Overhagen <marcusoverhagen@xxxxxxxx>
To: openbeos@xxxxxxxxxxxxx
Date: Thu, 16 Jun 2005 18:19:13 +0200 (CEST)

David McPaul wrote:

Hello David, I just subscribed with webmail to this list, so that
I can respond while not beeing at home.

I'll apreciate your work on the mov reader, but didn't have the 
time to check it in. Luckily, you now have svn access.

> On Wed, 15 Jun 2005 16:59:42 +0200 CEST "Axel DÃ¶rfler" 
> <axeld@xxxxxxxxxxxxxxxx> said
> > "David McPaul" <dmcpaul@xxxxxxxxxxxxxx> wrote:
> > > Whenever this message appears
> > > _SoundPlayNode::SendNewBuffer, event scheduled much too late, 
> > > lateness 
> > > is 35874

This is not a problem in the Sound Player. a new buffer event should have been 
processed
(by filing the buffer with data) about 35 ms earlier, but the system was too 
busy to do it.

> > > The cpu goes to maximum and the mouse stops moving.  On some movies 
> > > you 
> > > get enough mouse samples to do things but on other movies your 
> > > pretty 
> > > screwed.  Take that as fair warning.

The buffer processing thread runs with a very high priority, because they are 
very
short (around 10 ms), and don't need much time to be filled.

> > That doesn't sound too well, and could also point to problems in the 
> > Media Kit iself, not only in your code. Marcus?
I don't think that there is a problem. The SoundPlayNode code is pretty 
relyable.

> A further look I found that a thread called "<MovieName> control" gets 
> given priority 110 and this thread is taking the CPU time, the mouse 
> thread is only priority 104.
Thats correct, correct sound output is more critical than mouse, and normally
the control thread needs less than 1 percent CPU time.

> I will look for where this thread is started from.
It's started in BMediaEventLooper, and it's active when BSoundPlayer's 
buffer callback function is called.

Some applications use it to directly call BMediaTrack::ReadFrames from here,
which is not a good idea, because the data may need to be read from disk first,
and doing this when the data needs to be available in a few ms is just wrong.
A disk read with control thread realtime priority isn't good either, because it 
may
affect system performance.

However, BMediaTrack does some caching by using the chunk cache. 
If the chunk cache is active, it will cache some data for use by ReadFrames,
and uses a low priority thread to fetch the data into the cache. This works
pretty well, and so it's usually no problem to call ReadFrames from the 
control thread.

However, since you disabled the chunk cache in your first commit, this no 
longer 
happens. I wasn't very happy about that, but I hoped you would enable it again 
soon.

> Ultimately, the cpu issue is my code or something my code is doing to 
> confuse the audio output.  But I am  not sure a media control should 
> have such a high priority.

It must have such a high priority, for smoth playback.

Please try to enable the chunk cache and fix your problems.

If that doesn't help, try to put a set_thread_priority(find_thread(0), 5) 
into BSoundPlayer's before it calles the buffer callback functionm,
or into BMediaTrack::ReadFrames. But only for debugging, not into
SVN.

regards
Marcus

Machen Sie aus 14 Cent spielend bis zu 100 Euro!
Die neue Gaming-Area von Arcor - über 50 Onlinespiele im Angebot.
http://www.arcor.de/rd/emf-gaming-1

Follow-Ups:

[openbeos] Re: mov reader
From: François Revol

[openbeos] Re: mov reader
From: David McPaul

[openbeos] Re: mov reader

Other related posts: