XXHighEnd

Peter,

If I let XX play its playlist in unattended and finish by itself at least once (when it stops it brings back its frontend), then computer won't go to sleep anymore.

If I stop playing by launching XX frontend and pressing stop button, then it will go to sleep.

Can you please look into that. It is very annoying to wake up in the morning and realize that PC was up all night with its noises, although I expect it to go to sleep mode as I set it up.

BTW in either case PC won't sleep while XX actually playing. That is expected behaviour.

Thanks
Andrey

A longer time ago I told about this "feature", although I never realized this happens because of auto-restart of the front-end. But :

I don't think I will solve this, because my current Vista (still SP0) will go to sleep when I don't want that. Also, it is out of control because of bugs in SP0. So, it "solves" those bugs ...

On the other hand, I wouldn't know what to solve. Ok, *unless* it is really true that auto-bringing up XXHighEnd does that job, because then I could make an option that it won't do that anymore (which should solve your problem).

In any case I am not aware of anything explicit in there that causes this.


PS: My PC always keeps running, and I want that. The hybernate (or which ever state it exactly is and which I can't tell because I did not order for it) doesn't always end up in a proper restore after waking up. I forgot the examples, but for some (type of) SATAII disks just getting detached. Quite annoying !

PPS: Yesterday I have been working on moving the OS to a proven working backup (which failed so far) which will give me the opportunity to a. go to SP1 and b. install the english language as per your advise in the other thread. Then I will be able to judge better the current (= SP1) normal situation. I'll proceed on this ASAP.

One more thing, I think it may be related.

On my single core PC after XX has played at least once, all other windows sounds and sounds from other players are suffering from hiccups and cracks. If I reboot and never start XX all sounds are fine.

Hmm ... There is a thread somewhere (in here) where I related the "pending" hybernate (whatever :)) state to something else, which I forgot now.
This might prove this is just so. Maybe you know that thread, or otherwise I must try to find it. It may be important ...
I mean, important for those who find their PC kind of "destroyed" for other means of playback.

Andrey, is this general ? I mean, ASIO, Kernel Streaming, DSound just as well ? (I don't ask you to try this all, but you just might know it already).

WASAPI in Xmplay works fine no matter what

but ASIO and standard win32/DS gives crackling all over, after XX has played

Hey ... I recall the same reports from either XMPlay or Foobar !
If you want ... you may Google for it (somehow). But I'm fairly sure I recall reading that (might be 4-6 weeks ago, and I think it was about Foobar).

Nothing about blaming or "can't help it", but it might prove that it just happens when WASAPI has been used ... *also* meaning that when WASAPI itself obviously isn't affected, it just may cause it ...
Andrey, if you can't (or just won't) come up with this whereever thread, I will try to find it myself. Later ...
And anyway I will try to find the solution. Keep in mind though that this looks a bit similar as unticking those two checkboxes in the driver ("Aplications can control this device exclusively" and "Give applications with exclusive mode priority" (similar). Once unticked, you can't tick them and use exclusive mode again -> only a reboot helps.

Hmm ...

Another thing:

if I play XMPlay/wasapi, then audio never crackles after xmplay has played.

So it looks like xmplay does not destroy anything in windows audio and handles wasapi differently.

and foobar/wasapi does not cause sounds to break after it has played.

Seems like only XX ruins the audio stack.

Oh, that wasn't much clear to me before.
And you are sure you still use the single core processor for this ? (with multi core all is to be interpreted differently).

Yes it is a single core

And what if you leave the priority settings untouched ? (so, set to Nothing, reboot (!), play XX #3 and then use the other players).

I just thought that when this is all happening, I would be able to copy this behaviour by just using Engine#1;
Ok, just found something is really wrong with the latest version regarding this because it will just play all the tracks in the Playlist in paralellel, but anyway with one track in there, nothing is the matter ?? (note this would be Direct Sound).

I am not sure what the conclusion must be from this ... (at all)

Then I tried Foobar/WASAPI ... -> no problem.
Back to XX Engine#3 again (WASAPI) and after that Foobar Direct Sound -> no problem.

So what this comes to, is that you have something going on, I have not.
And no, I didn't try Foobar/ASIO.

But what ASIO did you use ? real ASIO, or ASIO4All ??
Similar would be Kernel Streaming; on Vista it officially does not exist without emulation (although I got it running some while ago in plain bit perfect mode).

:scratching:


PS: In all occasions I used the smallest buffer size possible.

I tried your scenario with no luck:

reboot->no problem->foobar/wasapi->no problem->XX wasapi-> problems
reboot->no problem->xmplay/wasapi->no problem->XX wasapi-> problems

And yes I am using "true" asio. not asio4all.

And BTW I have 3 audio devices: 2 PCI, 1 USB
Tried all combinations: disconnecting one by one etc.

Is it just me having such problems?

 :(

It is very strange, also because I really wouldn't know what can create this situation. Just like the subject of this topic with really the only thing happening is that XXHighEnd is started from within XXEngine3, so that is the only way to cause *that*.

You might try this (just to find the cause of the disturbed playback from other players, not the solution yet) :
In this post : http://www.phasure.com/index.php?topic=544.msg3900#msg3900 there's an attachment 96.dat. Put that one in place of the one you have in your XX directory, and keep the one you have save (and keep track of it, because when you forget to set it back after the test, you won't be able to play everyting !).
So, with the replacement 96.dat things might be different. I don't know, but it is the only thing the other players for sure won't apply, so it is a difference.

Btw Andrey, don't waste your time on this too much, and only do it for yourself when you think you need the solution.
Of course it will be me who is glad when it gets solved in general, so I will be very glad to find the culprit. No obligations on your side though !

No luck,

backed up file-> put the new 96.dat->reboot-> played media player-> no problem-> played XX-> stopped it-> played media player-> problem's there again(still)

:scratching::scratching:

Ok, thanks. I will try to think of some things myself. Don't know what yet, but still ...

A little update.

I made a simple app to use wasapi exclusive.
And made couple of simple tests.
Closing wasapi gracefully and exiting the app without closing wasapi correctly.

in 100% it showed that PC won't sleep as expected if you exit the app not closing wasapi properly.
and PC goes to sleep if you start and stop playing, exit and start app correctly closing wasapi.

Ok, so there must be a difference between a Playlist ending by itself on one side, and let XXHighEnd indirectly stop XXEngine3 on the other.

Thank you Andrey, I will look into this immediately ! (but there should be no difference ...)

Andrey, you are right !!

What I never saw was that the thread loading the tracks had become leading in determining whether playback has to end, and that this thread initiated a (startup of XXHighEnd and) shutdown of XXEngine3, that thread never being able to close down WASAPI objects properly. At the time I created this I never saw the difference, and later I never thought of this anymore. So indeed XXEngine3 can quit at two places, one of them being from within that thread, which just isn't allowed. I just solved that.

Another kind of problem is, that nowadays some 100 of situations exists that a quit is initiated from within that thread, althouh these are all error situations (except for playback has to stop because end of Playlist). I can theoretically solve them all the same, but I will be unable to test them. Most of them are theoretical situations anyway, but either way they just cannot be tested. And, because the only normal way which is there (and which is the one I just solved) has a return which is under my control, while all of the others may just jump out of the blue, I think I can do nothing else than leave those others as they are. They *are* real error situations (like format not supported), and in most (of not all) of cases, WASAPI won't be initiated anyway.

Andrey, good job !!
Peter