Playback may start with ... silence

[Calibrator]

I'm still getting the occassional lack of music start after the GUI disappears ... sometimes I might hear nothing at all and sometimes I might hear the hint of an attempt to start, then silence.

Hi Russ,

Is it so that this actually never went away ? I mean, you mentioned this before (a few weeks back), then at some stage reported all was back to normal. Although "all" was about quite some things back then, I thought you meant this one as well.

Not ?

I was likely referring to the changes you made to the GUI to resolve the gallery glitches and the OutOfMemory issues. These seem fine now.

Of late I haven't been playing a lot of complete albums where a lot of tracks have to be queued up, and that may be why I haven't noticed this lack of consistent starting. 0.9X-7 was pretty much bullet proof but I realise a lot of re-coding has happened since, which is why I think I need to revisit my scheme/priorities again.

Just changing the latter from 'Nothing' ( which I used to use ) to the defaults ( BelowNormal/High I think they are ), changes how the tracks are dealt with immediately after I press PLAY. Even though I have Start Engine#3 straight away ticked, if the priorities are set at 'Nothing' I have noticed that all the tracks get highlighted in blue before the GUI disappears and THEN the music starts. With the priorities set at BelowNormal/High, the music may start while the tracks are being systematically converted and before the GUI disappears. That is with scheme-1. Scheme-3 seems to change the speed of these pre-events a little, but introduces a few more audible glitches if I use the Alt-N or Alt-X frequently. In my mind it seems to be a timing or buffer related issue, but I need to see if I can find a set of parameters that works consistently.

If I have no luck in next few days I will turn logging on and see what that reveals.

Thanks,

RGB

[PeterSt]

Ok, I know the priorities and all make a difference at the setting "Start Playback during conversion", not that this can end up in silence. I will try it myself with your settings, though I think it highly depends on system speed in general (spread over cpu, disk I/O) and I may never run into it.
That all ends up in silence is unintentional of course.

For now, my settings are Scheme3, PlayerPrio Low, ThreadPrio Realtime, show all Covereart stuff and OSD stuff.
This never brings me silence, but *very* occasionally there's a hold on playback of 1 second during the conversion, and when that happens it's when all conversions just finished and the switch to "OSD Mode" is happening. "Very occasionally" means once per 3 days or so, but then I may be starting only 10 albums per day only.
"Hold on playback" means that everything just stalls (thus, is not skipped), which in previous internal versions could last many seconds and then was related to priority scheming. I think the first two 0.9y versions suffered from this too.
With this I only want to say there's a fair chance that someone using other prio - and merely scheme - settings, may suffer from similar or worse. We can see that these things play a role indeed, at a too small "priority distance" between Player and Thread Priorities, and playback just never starting before all conversions have been performed. Note that Engine3 starts allright in such a case, but it just never receives a single time slice because the conversions eat all.

FYI : the latter is by itself encouraged for because it is a kind of too efficient, and setup multi threaded. Those two threads (or more for more-core cpus) each will consume near 100% cpu, and nothing (or not enough) is left for the playback thread. Here you can see how important the Core Appointment scheming is, and although you (nor me) can reason out what will happen exactly at which scheme, it can work counter productive. for example, telling that Engine3 can run in Core-2 only (implying without disturbance from other stuff) will work only when other stuff is not needed there. However, with the conversions this is avoided (by me) deliberately, or otherwise you'd end up with the conversion running twice as long. So, the conversion will use Core-2 just the same (for half of its tasks) and *now* it suddenly becomes important how the priority relation is between Engine3 and the conversions (really being XXHighEnd), and I found that when the distance is too small (like "below normal" vs "high") Engine3 won't get enough time slices, never mind the higher priority. With "lowest" vs. "real time" this is not a problem (apart from those "very occasional" I talked about).

Peter

[Calibrator]

For now, my settings are Scheme3, PlayerPrio Low, ThreadPrio Realtime, show all Covereart stuff and OSD stuff.

A quick update before heading off to 

Using your scheme/priority settings above have allowed everything I queued up this evening (5 or 6 albums) to playback without problems

Also using 'split file' size of 100MB

First track of an album consistently starts playing now while the remainder of the tracks are being preprocessed. Will try loading up some hi-res albums tomorrow and see if that is stable also.

Was also able to use net browser consistently while playing ( yes .. in unattended ) without noticing any extraneous ticks or clicks either, so those priorities seem to have done the trick. It's doubtful I would have arrived at those so it's a good case for 'follow the leader' !

A couple of quick observations:

• Whenever the GUI is brought back ( whether by ALT-X or after completion of playlist ) the pathing text above slider isn't shown.
  
• At completion of playlist, the second last track entry is highlighted rather than the last. I think there was some discussion about this previously but can't remember whether this was being looked at or put in the 'too hard basket'

Cheers,

Russ