On Thu, 2013-03-21 at 09:10 +0100, David Henningsson wrote: > On 03/21/2013 08:05 AM, Tanu Kaskinen wrote: > > On Thu, 2013-03-21 at 05:40 +0100, David Henningsson wrote: > >> On 03/20/2013 04:45 PM, Tanu Kaskinen wrote: > >>> Hello, > >>> > >>> The target release date for 4.0 is 2013-04-18 (assuming 4-month release > >>> cycle), and that date is less than a month away. It's time to freeze > >>> soon. I propose 2013-03-28 as the freeze date - that would leave us 3 > >>> weeks to polish the release. > >> > >> Well, we should first release 3.1 with the stuff in the stable-3.x > >> branch. I think that can be done right away. > > > > OK. I guess it's mostly up to Arun to do that. > > > >> Other than that, I don't think I have any bigger objections. I would > >> like to push the buffer patches posted yesterday together with something > >> that documents maxlength as being okay to set in low-latency scenarios. > >> I could write that documentation patch this week if you can do some review. > > > > I can. > > > >> Providing "real underrun" callbacks (which the drain patch lays the > >> foundations for) would probably have to wait until a later release. > > > > Yep. BTW, I have forgotten why we need "real underrun" notifications. Is > > the application expected to do something different on real underruns > > than on stream buffer underruns? > > IMO, it's the current underflow messages that are useless. According to > the notes we however agreed to to add a new callback rather than > replacing the current one. I don't think the current underflow messages are useless (unless nobody bothers to use them, which is possible). They indicate that the application doesn't provide data as quickly as would be desirable, so the application should increase the buffer size if the use case allows the latency increase. Stream underruns cause rewinds, i.e. extra CPU load, so they are not harmless even if there's no "real" underrun. > Anyway, VLC once used an underflow as a sign that audio/video needed > resynchronisation. Finding out that the underflow callback in most cases > wasn't a real underrun, they chose to ignore the underflow instead, just > like most other applications out there do. I guess that's a good enough reason for the new notification. -- Tanu
