[openbeos] Re: mov reader

> 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.

I never noticed that but the R5 MediaPlayer does audio decode in that 
thread...
While not as dangerous as doing disk reads, it's not a good idea either 
to do any real computing at real time priority, because the more 
complex the code is, the more bugprone it is, the more busylooping-
prone it is.
And I know there are some issues with ffdecoder with for example mp3.
I already got CD Manager for example to lock everything up because it 
was doing bad things with the mp3 decoder at realtime priority (pets 
Marcus)...

> 
> 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.
> 

As said, the buffer callback should only just try to read something 
from a ring buffer of already decoded data from a non-realtime thread, 
or output silence if not data is available after a small timeout.
At least that's what nplay does:

http://clapcrest.free.fr/revol/beos/shot_nplay_audio_decode_thread.png
:P

But this doesn't have to do with mov at all.

François.

Other related posts: