XXHighEnd

Yesterday, I tried to compare 16/44 and 24/96 versions of the same file. Played the 16/44 file for about 30 seconds (all in unattended), stopped play and started play with the 24/96 file (I did not use alt/n to change to the 24/96 file). After the gui disappeared I received engine 3 stopped working errors, which is usually overcome by hitting alt/p again or by alt/x and then hitting play again. Alt/p generated the engine 3 error again so I hit alt/x and though XX appeared in the lower left side of the task bar the gui did not appear. Rt clicked and closed the xxtaskbar indicator and hit alt/x again but still could not get the gui to appear. Finally had to reboot. Went through this procedure again with the same result: reboot. This was the first time the gui totally failed to appear. I have had it not appear and then on a second try it does.

This morning I loaded the files again and tried to let them just play through. The 24/96 file was first. 4/5 of the file played and then I received the engine 3 error and sound stopped. This was followed by the Device allocated but cannot play error and a reboot. I have not tried 9-z1 cause I had many, many errors like this when 9z1 was first released. Just playing 16/44 files or just playing 24/96 files works fine.

One other thing. Though I did not have log activities ticked, 9zb was logging activities anyway. Sorta surprised me.

Before we continue with this, are you able to tell the difference with your (I think) daily mixing of different formats in one Playlist Area ?


Was there log data in files other than X3PB ?

Yes, am having trouble with "daily" playlists too (mixing 16/44 and 24/96 tracks). Going from  24/96 wave to  16/44 wave caused the sound of the 16/44 track to be "under water" followed by too many buffer errors. Earlier this morning when I was trying to compare versions of the same track I was using flac files. Logs of both sessions are attached. I have a feeling this might have something to do with switching to Scheme 3 several days ago. The sound seemed better but I started getting a lot more "Engine 3 won't start" error. Will switch back to scheme 2 now and see if that makes a difference.

Log files in 5 am hr were with the two versions (flac) of the same file. 7 a.m. hour was regular playlist.

Same problems with Scheme 2.

I didn't look at the log files yet, but wouldn't you say this is about the good old problem I never could solve for you (although that was about Engine#3) ?

Might just be. But I just tried those flac files of the same track in Scheme 2 and they played, 24/96 to 16/44. WTF  :wacko:

Here are the log files from that last successful effort, scheme 2.

Allright ...

In the situation with the buffer errors you had the Device Buffer Size set to 4096 and Q1 to 2. I can't explain it, but I feel this can't work. Anyway, this will have been the cause of *that* situation not running.

About the remainder ... It can't be a coincidence that you actually have the same problem now with Engine#4 as you always had with Engine#3. Notice that both methods of producing audio are totally different, and it *must* be something inherent in your system that doesn't allow the swap (between sample rates). Now, at looking at your log files, I thought of this :

Whatever it is in there - and I am not sure whether it can be the DAC dictating this -> but which is the common denominator wt using the HiFace now which you didn't have before) - it may disallow a change while the before buffer is not played empty yet. By itself nothing less than logic btw, and I may wonder how I deal with that myself (read : nothing explicit, and it works for everyone, but not for you).

On a side note, let's keep in mind that earlier with KS (Engine#4) you already had a problem like this which could only be overcome with a reboot; as strange, but as related I think.

Also notice that I tested the HiFace myself, and saw nothing strange in this area.

Something like the HiFace will not be much different than the DAC at the far end, if it comes down to communicating over an agreed protocol - that protocol simplified to the proper bit depth and sample rate. So, what the HiFace sends out, must be received by the DAC by the agreed protocol (bit depth / sample rate). Now, if the DAC is still playing its last buffer while the HiFace already changes the protocol (the next track is not 24/96 but 16/44.1) I don't know what happens, but the least thing what should happen is that it goes "wrong". But what also can happen - in a more friendly way - is that the Hiface (or whatever front-end to the DAC) tries to change the protocol, while the DAC says "not yet" and next an unsupported format (at this time !) is reported. I say it again, the two means (WASAPI and Kernel Streaming) are too much different to ignore this similarity.

If I had to put my money on something, I would say it is your DAC doing it to you;
It is good to know whether this is right or not, or IOW it would be good to proove it. Now, I am not sure whether the HiFace can be used unconnected (to the SPDIF side) but I think it can. It may be the most easy way to proove it is the DAC or not, or otherwise you'd have to connect another DAC.

You know we have already spent an alphabet of XX versions on this (wasn't this a year ago already ? :swoon:), to no avail. I never thought of something like I wrote about in the above, so maybe there is a clue in there.

Peter