XXHighEnd

In attended mode  (not UNattended)

Calculation of song length is OFTEN much longer than actual.

This results in a song ending and then going into silence as I watch the progress slider move to the right for a couple of minutes until it reaches the end. 

This happens with AIF, FLAC, high res, and low res too.   I have very few WAV files.  [Editorial: this problems seem to be related to a rate change with fx on.  Maybe.]

[the next problem I will report on #2 of 2 is tied to recovering from this problem, also attended.]

[Please don't ask why I'm using attended mode.  To make a long story short, it sounds better than 7-4 and gets around UNattended problems that I've not reported yet]

Although MAYBE I could make this more decent, it is you
yourself doing this. Well, I'm fairly confident about that. So, it is officially allowed to click on another track than the one which is playing, and once you are going to do such things, you will activate the time for that other track.

But this is not all what's involved ...

That other track can also be of another format, and now things get nasty.

Clear solution : Don't allow clicking on these other tracks while playing. However :
That this is allowed is explicit and for a reason (I don't know anymore).

I'm afraid this is as it is, but it will be you encouraging for it.

It will be true that this is related to your other 2 problems as well.

Charlie,

I was just thinking ...
I would have been more simple (and less "aggressive" (though well meant) from my side) to ask you for a clear situation when you receive this anomaly. So, you sure will be able to do this, but then I can more to the point lay out what you should have done "better" OR I would have learned in what very normal (for usage) situation this goes odd.
So, if possible a step my step guide for me to mimic such a situation. Ok ?

Thanks,
Peter

No,  I'm not doing that (clicking on another track).

I apologize for not giving a more detailed explanation before.

To recreate the problem, do this:

• Work entirely in Attended Mode
• Clear your playlist.  Make sure fx is turned on etc.
• Go to your Nice Stuff directory.
• Select a good number of albums and make sure you select some with mixed resolutions and sample rates.
• Right click and choose random play.  This should create a long playlist.
• Now play the list and be prepared to realize that something is not working like it should.

At no time should you click on any other track.

If that alone does not recreate the problem, then try this:  Stop playback.  Select a track somewhere in the middle of the long playlist.  Start to play it.  You should soon see a problem.  This simulates restarting the list from where you left off the day before.

Just now I tried letting it run.  Just hit play and never again touch the mouse.  Everything played okay until: 5 songs into the list, a 96KHz 24 bit, 1 minute track.  xxHE erroneously calculated it as a 2 minute song.  Song ended after 1 minute of play.   xxHE Kept playing silence until the end of the erroneously calculated 2 minutes.  Then the track progress indicator stopped at the end and nothing for about 30 seconds more.   Then the following error messages poped up in succession:

Error window 1: Audio device could not be determined

Error window 2: Engine #4 did not start in the expected time

Error window 3: Windows OS error saying xxEngine3 stopped working

Charlie,

Without looking into it yet, I'm afraid that this all was introduced with 0.9z-7. Maybe even a version into that. So, I tried to solve "length" issues from HDTracks files and I'm fairly sure this can cause problems elsewhere. Testing it all is undoable.
I even recall a change in 0.9z-7-5 itself ...
IOW Charlie, while I was pretty firm in my "hey this all works", I forgot about these changes. So I must apologise ...

That being said, can you please be more specific about
a. those Hires files (origin);
b. your playback means (all I see in your sig is No Arc Prediction).

And do you actually say that with Unattended you don't see the problem ? (I ask this because you are the first reporting about this and *if* Unattended doesn't give the problem it could be more easy for me to find the solution). If it is more difficult for you to test this, that's fine.

Can you recognize that in earlier versions this wasn't a problem ? (the answer to this is crucial)

Thanks ...
Peter

a. At least one of the HiRes files is an HDtracks:  Paul McCartney _Band on the Run_ the uncompressed version.  I believe it is 96KHz.  And it had errors.  Others may be from non-HDtracks, I will have to check.  (Not to stick it in your eye but JRiver  has no problems with any HiRes material of any kind in my collection).

b. 2x upsampling with no method selected (repeat bits).  fx usually on, but last night I tried fx off and the problem still occurs (the only difference is that high res files play at 88 or 96 with fx on, and at 176 or 192 with fx off).  Of the two options listed in my sig, I'm using adaptive right now, with 15ms requested).

--

Correct, generally I do not see this problem in UNattended.  Instead, I have another problem I have reported in the past, better, but not totally fixed; namely, the high res tracks sometimes stop playing short of the actual length, but at least it moves on to the next track.

Correct again, in version 6, I was not having this problem.  Instead, it did not allow format changes at all.  So playback would stop.  I'd start it manually.   That was better.  And as I recall, version 5 allowed format changes with fx on, and that worked mostly okay I think (it was a long time ago) but was not perfect. 

However, this problem of Attended (not unattended) also happens with low res.  However, I think low res plays fine until it first encounters a problem with high res.  After that, both can miscalculate.

Another hint: If I load that same McCartney album all by itself, I believe 99.9% that it will play Attended with no problems.   

Another hint: The track times shown in the mixed playlist is wrong, they are too long to begin with.  So I think the bug is in the pre-calculation of the song length from the start, and perhaps only in mixed playlist mode, maybe even only in long mixed playlists.  Once these are miscalculated, it makes sense that the player would play them the way they are played with long gaps of silence.   (But this does not explain the error messages if left alone.)

Thank you Charlie.


So for now you can deactivate Allow Format Change and it would be "better". Right ?

I will solve it !
Peter

Actually, I didn't think of that.  I'll try it.   Grumble grumbe...  for now.  :naughty:

Disabling Allow Format Change had mixed results last night.  In the repeated failure, almost the same things happened: Got the cannot allocate audio device message, and then afterwards trying to start the next track manually met with the same non-playback, even after hitting the Play button several times.   Hitting stop and Play repeatedly got it going again.

So not much help.   But I do think that one high res track played correctly, and with the correct time. t think of that.

[note: my sig has been updated]

A few new hints for this problem"

1) What do you suppose unchecking Allow Format Change did to this song length calculation problem?

Answer:  Very few length miscalculations.   But I still have to manually deal with all of the other problems (errors messages, Next does not work,  clicking on Play does not work usually,  sometimes clicking Play two or three times starts to play finally, and sometimes nothing short of killing engine #3 and exiting xx and restarting allows me to continue.   But few length miscalculations.

2) What do you suppose dropping SFS from 60 down to 8, 20, or 30 did?

Answer: It often works, not always.  This means, even checking Allow Format Change sort of works, not fully.  In a short amount of time, a 44.1/16 flac file had the wrong length and I let it play through the silence until the end (about 1min) and it kept playing.  This is no solution because the sound is not nearly as good at these lower SFS levels and clicking happens every now and then, which never happened before in xx for me.

Thanks Peter

[BTW, I vote for the behavior or PE *OFF* as implemented in 0.9z-7-4]

Charlie, point is : I expected the whole thing to happen in OK fashion with Allow Format Change being Off. But apparently that doesn't matter. But it also should imply that pressing stop on the one track, clicking the next and press play won't help just the same. And I think you already said a kind of like that.

But let's not be speculative anymore (my side) because I must look into it which I did not do yet.

Peter

That's correct.  It doesn't help much.  Helps sometimes, but even then, I have to repeatedly hit Play to get it to start (even though the red Play LED light indicates that it is attempting to play from the first manual click).  Other times, exiting Engine3 and xxHE and restarting is the only way to proceed.

Well, FYI : It it is worse. Of course we are at 0.9z-7-5 already, but that one doesn't allow any format change at all (again). So I haven't even started to mimic your behavior.
And strangely enough, *after* 7-5 I again applied changes (HDCD related) and that worked. But actually nothing works.

Point seems to be indeed that sometimes it does work. And repeatedly. But do something else in between and for the life of me I can't get it going anymore. This must be what you are experiencing ...

(no further help needed - yea, a shrink !)

Okay, should be solved for 0.9z-8.

This is all a tad more complex than it seemed at first;

First off, there's 0.9z-7-4 which (IIRC) did not solve the "pitch" problem yet. Not sure, but the changes were all related to that. So, what happened (or could happen) is that the change from 44.1 based to 48 based (or the other way around) did not change the sampling speed in the DAC. It played, but with a pitch which was ~10% off. This is a sort of anomaly in the Windows sound kernels, but in the end happened because I did something wrong myself.
Notice that with "combinations" this would imply the running time being of for that 10%. And, this is very different from a wrong track length callculation, which *also* was subject to changes in the latest versions (and that again implied by wrong header data from HDTracks and more).

Still there ?

While I solved those issues, I did not see or ran into the fact that when the sample rate changes, this can't happen when the previous is still playing. Now things get odd, because this is a kind of out of my control. This is buffers still playing which
a. can't be shut off because it would go silent suddenly;
b. the inability to see that a buffer still plays program-wise.

It is the latter which can cause it one time being all right, and the other time not. All sheer coincidence; the last buffer just played or just not. Depends on the set buffer sizes as well.
(this is how I could approve my own changes in 0.9z-7-5)

Not it gets tricky;
For 0.9z-7-5 the pitch problem was solved already (but careful because maybe it was earlier). What was *attempted* to solve were the track length header errors, and this can't be tested by me because it depends on the specific album or even track. So, notice that this was an ever pending problem for 0.9z-6 (last version of that) and since 0.9z-7 I didn't hear of that problem anymore. But also : this is fairly hard to detect because only a handful of XXHighEnd users ever play Hires. This is testified by nobody coming up with 0.9z-7-5 actually not being able to switch formats anymore (but as said, it could go all right by accident). Or, what you said yourself Charlie, that before version XYZ formats wouldn't change at all. I was only notified of that months into that version (and never noticed it myself). So ...

So no guarantee that 0.9z-8 will be OK on this. The examples I tried look fine, but it doesn't tell much.
To be clear : for 0.9z-8 I did NOT change a thing to the track length calculation; in 0.9z-7-5 I did, but you are not using that (and remember : never mind because it won't work for the reasons described above anyway).

On a final notice and just FYI : The whole thing started to go wrong (0.9z-6) when the sound engine was to stay in memory just to keep on allocating the Contiguous (SFS) Memory. So, before when a format change occurred, the sound engine was just restarted and it couldn't go wrong. Today it has to reinitialize things properly and that is tough enough already. And, as described, it now also is related to the device being allocated, reinitialize it when needed, but not too soon because it is still playing (its last buffer and which can't be detected).

See ? all rather complex.
:wacko:
Peter

Yes, I'm with you and yes, I see.

- Something is missing in the analysis because although it is true that sometimes it is only about 10%, most of the time it is closer to 100%, meaning 2x.  So if a song is calculated to be 2 min, that song actually ends at about one minute.

- I had previously stated that reducing SFS to 8, 20, or 30 makes a big improvement.  Well, now I realize that this is only true if I first play something in UNattended mode and then later attempt attended mode.   If I boot the machine and from the start I start a long playlist, it will fully exhibit the problem from the start, even with SFS=25.

- Since I can't get straight contiguous to work at SFS sizes greater than about 2, I use mixed contiguous.  So why not a temporary solution with a checkbox to always initialize the engine so that it can't happen?

Last night I didn't have this problem for the first time.  I didn't try extensively, but I did try a few tracks of different sampling rates and bit depths in a row.

It appears 0.9z-8 (version 8 for vista) solves this problem! 

Thanks and I'll report if this is not so.

:xx:

Thank you for the feedback Charlie.