[haiku-commits] Re: BRANCH orangejua-github.media [87db227] src/kits/media
- From: Julian Harnath <julian.harnath@xxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 19 Oct 2013 21:50:51 +0200
Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> schrieb:
> On 19.10.2013 19:15, orangejua-github.media wrote:
> > 87db227: Switch SoundPlayerNode run mode to B_DROP_DATA when its
> > latency
> > gets higher than buffer duration.
>
> Don't you pretty much remove the B_INCREASE_LATENCY run mode this
> way?
> Maybe I'm missing something, but when I use that mode, I intend the
> latency to increase until dropping buffers can be avoided completely.
> Is that still happening?
Yes, it will increase internal latency, but only until it reaches the
buffer duration. As soon as latency becomes greater than buffer
duration, it switches to B_DROP_DATA. The buffer duration is an upper
boundary for allowed node latency, going higher only causes problems.
Consider as an example, a SoundPlayerNode connected directly to the
sound card's node. Let's say audio buffer size is 10ms and the
SoundPlayer's latency is 5ms.
Audio buffer duration of 10ms means: the soundcard must receive one
10ms buffer every 10ms. It's a hard realtime condition. If it's not
met, the user hears dropouts.
The SoundPlayer node has a latency of 5ms, so there is no problem: it
guarantees that it can fill 10ms worth of buffer bytes within only 5ms.
It can easily supply a buffer every 10ms.
Now assume that something happens and the SoundPlayer node increases
its latency to 20ms. That means it now takes 20ms for data to travel
from its initial stage to the output of the SoundPlayer. Now we have a
problem! Because...
* Only one buffer can be processed by the node at the same time.
BMediaEventLooper dispatches events one after another, there is
generally no "pipelining" inside the node, events are processed
sequentially.
* From begin to end of the node a buffer needs 20ms. The node needs
20ms to fill a 10ms buffer. This breaks the hard realtime condition, we
cannot produce 10ms of audio data every 10ms anymore. There *will* be
dropouts!
We must switch to B_DROP_DATA at this point. Otherwise, all events we
send out will be late because the node simply can't keep up with the
required data rate anymore. Nodes further down the stream might get
confused because the lateness will keep increasing: first buffer will
be 10ms late, second 20ms late, third 30ms, and so on...
The node which causes the contention must drop buffers and not just
send buffers with ever-increasing lateness down the chain.
I hope this makes it a bit clearer... to understand it properly myself
I drew a bunch of timelines and stuff on paper, I could partially
replicate that here in ASCII-art to make it clearer, too :-)
--
So long, jua
Other related posts:
