OSD Timer and its influence

[Calibrator]

Since the advent of KS Special Mode and it's very low latency capability, I have been tinkering with settings trying to eliminate the low level clicks and plops I have been hearing when initially hitting PLAY, and then occassionally throughout the play sequence. Up until a few days ago I had always had the OSD Timer showing, but on a whim disabled it. The improvement was immediate and noticeable. No longer was I getting the clicks for the first 5 seconds or so on initial playback, and the occassional low level click has been reduced to one every 10 minutes or so. Not perfect, but I figure it may be attributed to the very low Q1 and buffer setting I use. I would NOT want to change those settings ... they are here to stay!

For me then, the OSD Timer is a no go, and it's disabling may well help others experiencing occassional clicks.

Peter, if it's on your agenda to look into an improvement for this feature that would be great. My use of the OSD Timer was only for a rough idea of where I was in the track, and never used it for critical timing information. Even if it only updated every 10 seconds or so, it would be suitable for me. I expect the problem I am experiencing eminates from the screen update happening at a critical system time. These low latencies probably don't allow much margin for error in timing.

Cheers,

Russ ( still with a huge grin revelling in the sound )

[PeterSt]

Hey Russ,

As happens more often, you may have been fast on the downloads, but slow on the reading of the Release Notes . That is, IIRC I promised just that at one of the first ultra low latency versions. So ... you are correct.

It just takes too much time to draw the pixels on the screen in relation to how fast the internal response must be for your (crazy) 2 samples latency. Well, if you still have that.

I can't really gain on anything anymore, except for drawing the individual digits instead of all four of them. That's a kind of tedious operation but *is* something to do. However, I didn't, because I was thinking about a slowly filling slider with the "digits" fixed on the screen. So, that would be way smart, so to speak, because it requires a faction of the pixels to draw compared to right now, plus there's less internal intelligence needed for "following" the font. All 'n all it can be a rough 1000 times smarter, but it needs a redesign of the OSD screen;
Once I start with that I have some more things in mind, which is why I don't start it. haha.

For now it is like it is. For me, with 22 samples, I only hear the OSD Time clicks in the beginning; not after that. But as we can imagine, what we can't hear - though is there, we *will* perceive ...

Peter

[Calibrator]

Hey Russ,

As happens more often, you may have been fast on the downloads, but slow on the reading of the Release Notes .

haha ... guilty as charged about the fast downloads, although I do read through your release notes diligently each time, quite often more than once. I vaguely recalled mention of the OSD Timer's "frailty" back in January, I think it was, when you first introduced your revolutionary KS playback model, and at the time everything seemed fine in that regard, with respect to the timer.

It wasn't until the ultra low latencies were achievable that I noticed some irregularities, and my post above is more a form of feedback to you.

I like the idea of a progress bar, and if you can achieve it with minimal system disruption, it will be used here for sure.

Thanks as always,

Russ ( the couch potato during today's Melbourne Grand Prix telecast )

[PeterSt]

Actually it is just good that you mentioned it, because I thought it was harmless in the end (apart from right after the start in my case).
Btw, this would be a typicle example of "may need a reboot" and then it doesn't bother anymore (that close/fragile it is).

So, "thanks" of course, instead of accusing you about whatever. It was not meant like that, and I was merely joking around a bit.


Very nice race this time, with dutch weather ! A pitty Webber missed his points; it wasn't his fault.
Peter

[Calibrator]

So, "thanks" of course, instead of accusing you about whatever. It was not meant like that, and I was merely joking around a bit.

I think I understand your humourous side by now Peter and I didn't read anything into your comments, other than a little tease. It's a common occurence to forget things when one approaches 100 


The GP was a huge turnaround from a spectator point of view from the last race. I reckon the FIA should retrofit sprinklers to all tracks now. At first glance I thought Webber's late race mishap was caused by an frustrated Hamilton trying an over aggressive overtaking attempt, which dragged him into it, but post race, Webber apologised to Hamilton for running into him. He blamed lack of downforce while braking the reason for it, and he was simply following too close. Mark should have known better though.

I was glad to see Button get the win as he deserved it by being the smoothest driver that nursed his tyres.

For the next race I would like to see Fernando get the win, and every one after that 

Cheers,

Russ

[PeterSt]

... which will be a tough job starting almost as last.

again :

About Webber and my own experience as a rally driver ... I don't know;
If you drive your own race you have your breaking point, which is for say, normal breaking. Now however, the two in front of him were breaking exceptionally late and exceptionaly hard with it (I thought it was a miracle that Alonso stayed on track). This will always mean that the man behind such a situation (Webber) has to break earlier than normal. So, no matter the both on front of him breaked later (mind you, which is about 1 or 2 meters only), it *will* mean that you go into the turn more slow than usual (plus that you will loose on the next straight). So it is this what "killed" Webber, and in the end nothing much different from how the late Senna managed to have a headstart at each turn with a straight behind it. Btw, you may have heard the (in fact ridiculous "advise") radio contact towards Massa about the exact same.

And as we by now have seen, Webber obtained himself a nice revanche ...

Peter


PS: About those sprinklers, we said exactly the same here !

[PeterSt]

Something like this ?

(btw, this album gives you the shivers, chicken skin and what not, brrr)

[Calibrator]

Something like this ?

That works for me.

May I suggest an alternate idea? Do away with the 1/4, 1/2, and 3/4 numbers and just have the markers present. The markers for the 1/4 and 3/4 can be a little shorter than the one for 1/2. I would also think it more visually pleasing to have the bar starting at the left side. Your eyes are already looking down there looking at the track name .

You would need to figure out a way to scale that progress bar if a particular track exceeds a certain limit, say, 20 minutes. That way the bar can represent 0-20 mins, 0-40mins, 0-80 mins. I doubt there would be tracks longer than 80 minutes as they wouldn't fit on a redbook disc.

Food for thought ?

Cheers,

Russ

[PeterSt]

Hmm ... maybe that is better, yes. I had it like that at first, but didn't think of the 1/2 bar sticking out a little. That makes the difference.

Try to imagine that I solved the problem of "too long tracks" by starting in the middle, and ending at the end of the screen. Notice that 20 minutes will fit on a 1280 screen (1280 pixels if progress is per one second). So, a longer track starts outside of the screen boundary at the left. This seems better than the end of the track running off the screen.
Of course I have thought of some scheme which would be infinite, but it's really a tough thing to do. So I keep that for later. But also, it needs the logic in the program which takes cpu cycles. And as we already know, at the very low latency more cycles for this are needed than pushing through those 2 samples. Well, as it was. Not so anymore, but we must be careful that it doesn't end up like that again.

Thanks for the ideas. Anything else ? please let it know.
Peter

[Calibrator]

So, a longer track starts outside of the screen boundary at the left. This seems better than the end of the track running off the screen.

Of course I have thought of some scheme which would be infinite, but it's really a tough thing to do.

Thanks for the ideas. Anything else ? please let it know.

ah ... I understand what you are trying to achieve. Yeah ... should work OK ending on the right side then.

Well curiosity got the better of me this evening, as I wanted to get an idea of the typical playtime distribution, so armed with trusty Tag&Rename, I exported a snapshot of one of my music drives (just over 90,000 files), and imported into Excel. With guidance from my Excel guru brother, I now have a pretty distribution curve that may be useful.

It would appear that a progress bar of 20 minutes should cover well over 99% of typical tracks. I have some reaching out to just under 60 minutes, but these are typically from the likes of Klaus Schulz who is renouned for that.

Hope that helps.

Cheers,

Russ

[PeterSt]

Haha, nice. Well, I fugured something like that. So, for the few you will be in the blind for a while.
But later I will spend some more time on it.

Thanks,
Peter

[JohanZ]

Do away with the 1/4, 1/2, and 3/4 numbers and just have the markers present. The markers for the 1/4 and 3/4 can be a little shorter than the one for 1/2.

I don't know what you mean with the 1/4 , 1/2 ...., but I hope we keep the indication in unattended mode the track and total track indication. I'am still using the 8" screen. I soon hope to use the 10" (iPad).

[PeterSt]

Just look at the screen copies. 1/4 = 15 seconds, 1/2 = 30, 3/4 = 45.

640 (x480) can contain 640 seconds of "active tracking".
Otherwise the old method will always be there (but this is audible at ultra low latency levels).

Peter