search for: _long

.....64d418a 100644 --- a/metadata/core.xml.in +++ b/metadata/core.xml.in @@ -44,6 +44,13 @@ <min>0</min> <max>10000</max> </option> + <option name="edge_delay" type="int"> + <_short>Edge Trigger Delay</_short> + <_long>Duration the pointer must reset in a screen edge before an edge action is taken.</_long> + <default>0</default> + <min>0</min> + <max>10000</max> + </option> <option name="close_window" type="action"> <_...

...in my packages), I was still looking for a way to define the default plugins uses if a gconf backend was used. So I patched core.xml.in as follows: --- a/metadata/core.xml.in +++ b/metadata/core.xml.in @@ -7,6 +7,23 @@ <_short>Active Plugins</_short> <_long>List of currently active plugins</_long> <type>string</type> + <default> + <value>decoration</value> + <value>png</value> + <value>wobbly</value> +...

Is is possible to give a short hint about how the jitter buffer would "catch up" when network condition have been bad and then get better? I'm using the jitter buffer with success now, but sometimes I have a long delay that's caused by bad network conditions and then later when the conditions get better, I would think we would want the audio to gradually catch up with real-time

I have made claims that I have not left the compiz project and that I have been maintaining it over the past 4 years, despite the lack of releases by not fault but my own. At the request of some of the original compiz developers, I am now posting a compilation of some of the contributions I've made over time, since the beginning. Since the most important contributions are code and easiest to

...packet was 40ms after the current timestamp, the 40ms bin would be increased. If this packet arrived 60ms too late (and hence is useless), the -60ms bin would increase. early_ratio_XX is the sum of all the positive bins. late_ratio_XX is the sum of all the negative bins. The difference between _long and _short is just how fast they change. If a packet has timestamp outside the bins, it's not used for calculation. Now, clearly, if early_ratio is high and late_ratio is very low, the buffer is buffering more than it needs to; it will skip a frame to reduce latency. Alternately, if late_ra...

...timestamp, the 40ms bin would be increased. If > this packet arrived 60ms too late (and hence is useless), the > -60ms bin would increase. > > early_ratio_XX is the sum of all the positive bins. > late_ratio_XX is the sum of all the negative bins. > > The difference between _long and _short is just how fast they change. > > If a packet has timestamp outside the bins, it's not used for > calculation. > > Now, clearly, if early_ratio is high and late_ratio is very > low, the buffer is buffering more than it needs to; it will > skip a frame to red...

...hence is useless), the -60ms bin would increase. Right. > early_ratio_XX is the sum of all the positive bins. > late_ratio_XX is the sum of all the negative bins. Right. And only the packets that are "just in time" don't get counted in any ratio. > The difference between _long and _short is just how fast they change. > > If a packet has timestamp outside the bins, it's not used for calculation. > > Now, clearly, if early_ratio is high and late_ratio is very low, the > buffer is buffering more than it needs to; it will skip a frame to reduce > la...