search for: _short

...with the GUI tools now (so it will probably become default 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> +...

...ta/core.xml.in b/metadata/core.xml.in index 8424ab1..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...

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

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

...s 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_ratio is even...

...sure :) >> 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. Well.. they're counted in the ontime_ratio_long and _short, right? One thing that might be worth mentioning: the sum of all the margins will never be higher than 1.0, so a test for early_ratio_short > 0.7 means (roughly) that 70% or more of the packets in the last short-term time period were early. >> Depending on your chosen transmission met...

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