Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AndrewFG]

PS you said that the difference between the first play and the second play attempt is that in the second case it has to purge the memory, but in the first case not. That makes me think that it is the purge process that causes the freeze, rather than the load process. Is there any way I could separate the purge from the second load to test this hypothesis?

[AndrewFG]

PPS I am running on 64 bit so perhaps the 64 bit purge code differs from the 32 bit code? Perhaps an integer pointer wrap overrun thingie?

[weedub]

Ok!this is going to be a bit of a rave, although I hope to show that if you commit to the details you can have something very special and your playback and computing in general is reliant on the "Sum of the Parts" (you must pay attention to the details)

I would like to express my thoughts on memory playback with JRiver(64Bit) and how it works for me.  I have one issue that is not hard to deal with.  When loading a DSD (.dsf files) full album to memory, there is a 40sec freeze of the UI before the album starts to play.  This happens in standard view, and in Theater view and will not allow me to do anything else until the album starts to play.

I can quickly press the windows key to return to the desktop and continue.  I think that a setting to minimize the UI on play would be useful, so that the album can load in the background.

My system plays all my DSD(.dsf) very well with only this issue, the files are stored on a NAS and are streamed to the PC (windows 10). The network is (Gigabit) and file transfers range between 95 and 130Mb per sec,My PC motherboard is a Gigabyte Z170X Gaming 7 with a i7 6700K and 16Gb of 2666 memory and the motherboard has DAC UP (isolated USB Ports) I use USB audio to a OPPO HA-1 that I use as a Class A pre amp and that has balanced connections to a Pair of NCore mono blocks I assembled myself, and the final link is a pair of Audience 1+1 V2+ and a JL Audio F110 sub woofer, this is used without the Audience speakers using the sub crossover,and is balanced just to fill out the bottom end.

I hope someone finds this info useful.

As I mentioned before I think that a setting to load the full album in the background with the UI minimized would be useful.

Thank you.

[AndrewFG]

Attached two screenshots of the MC crash caused by full album memory playback. After the crash Task Manager shows 0% CPU and 167MB RAM. This RAM figure looks rather low for a full album, and perhaps more like the footprint for a single track. (Although perhaps Windows might have reclaimed some RAM before showing the crash dialog??)

EDIT: I just checked the actual track sizes. The album being loaded has 6 tracks on it, whose sizes are 33MB, 55MB, 52MB, 18MB, 37MB, 37MB respectively; or 231MB in total. The post crash RAM footprint of 167MB is less than this; perhaps indicating a) that not all tracks could load (e.g. the first four tracks add up to 157MB), or possibly b) the 167MB footprint is that of the previous album (which had successfully loaded and played).

[Matt]

Hi AndrewFG, could you send a crash dump to matt at jriver dot com?  Not sure if it'll show anything, but certainly worth a look.  Just "Report a Problem" on the logging dialog after the crash to make a zip file you can send me.

[AndrewFG]

Hi AndrewFG, could you send a crash dump to matt at jriver dot com?  Not sure if it'll show anything, but certainly worth a look.  Just "Report a Problem" on the logging dialog after the crash to make a zip file you can send me.

In the meantime I upgraded to build 70 (64 bit), and it seems that the problem has (therefore) gone away.

I guess that the code you added to monitor the time to load the album into memory was what fixed it. I guess the loading is now not done on the UI thread, the time monitoring is on another thread, and the eventual timeout pop up dialog would be put on the UI thread if it happened; and that thus frees up the UI thread so it can to breathe, and be seen by Windows to be breathing. (??)

Anyway the freeze crash does not occur anymore. And also the TheaterView UI seems to be a lot snappier during the memory load process than it was before.

EDIT: for what it's worth, I was using the OpenGL renderer for TheaterView, which might explain why others had not seen the issue. Just a thought.


PS Jim, it was evidently certainly nothing to do with Norton..

[JimH]

PS Jim, it was evidently certainly nothing to do with Norton..

Yes, we know that now.

[AndrewFG]

I always did

[JimH]

We know that, too.

[AndrewFG]

 

[AndrewFG]

I think I found another bug.

If you have an album loaded in memory and are playing one of the tracks. Then sleep the PC, then wake again, then MC hangs. It's easy to understand how that could happen.

I guess the safest approach here would be to detect the wake events, and reload the memory image in such cases.

[Matt]

If you have an album loaded in memory and are playing one of the tracks. Then sleep the PC, then wake again, then MC hangs. It's easy to understand how that could happen.

I can't reproduce that.  I sleep and wake up and it just keeps playing.

I wouldn't expect loaded memory to change at all due to a system sleep and resume.