- #MINIMSERVER CHANGE DRIVE DRIVERS#
- #MINIMSERVER CHANGE DRIVE UPDATE#
- #MINIMSERVER CHANGE DRIVE DRIVER#
- #MINIMSERVER CHANGE DRIVE WINDOWS 10#
- #MINIMSERVER CHANGE DRIVE PC#
#MINIMSERVER CHANGE DRIVE WINDOWS 10#
Hi Dev! I run a Lenovo Thinkpad x201 with Intel Core i5 (dual core), 4GB RAM and Windows 10 Pro (upgraded from Windows 7 Pro).
#MINIMSERVER CHANGE DRIVE PC#
if you don't mind sharing, what is your pc configuration - like CPU, ram etc ? Any bios tweaks that you may have done ? what version of windows - is it running in gui mode or core mode ? Its quiet possible that there is some resource crunch in terms of compute in the jstreamer/minimserver case.
#MINIMSERVER CHANGE DRIVE UPDATE#
I will update the thread as I find more info. This does look like some kind of cpu resource contention but I have no idea how PL/Windows does the scheduling. What was confusing is how foobar as media server worked under the same constraint but its also interesting to note that if I mark minimserver as a game process in PL, the problem would repeat in an album (not for every song). After assigning more than one cpu to jplaystreamer, the problem seems to go away - atleast I could play an entire album but I haven't tried all type of files.
Surprising I was just about to ask if jplaystreamer is a multi-threaded or not. That was it and what I suspected as well. (And of course this timeframe gets much shorter with larger DACLink). JPLAYStreamer has separate threads for streaming from MusicServer and streaming to JPLAY (for playback) so if it gets 'locked' to single core it is very much possible that playback-related thread gets paused just long enough to cause buffer underflow i.e. > Found that I was using ProcessLasso which marked jplaystreamer as game & realtime process and cpu affinity to just one core out of the four. Will have to wait and see if it fixes the issue but what I am mostly interested is what are the recommended configurations on the control pc for higher DAC link when using jplaystreamer/minimserver/kazoo ? All these seems to indicate that this is a resource management situation where things have to be kept at very tight and predictable low latency in order to satisfy the higher refresh rates. Next I limited the minimserver to just 1 logical cpu (7, the last one) and it seems to play so far for about 15mins without stopping. This scheme was lot better, though it eventually stopped after playing continuously couple of songs. Surprising, PL automatically changed CPU affinity to 0-7 for the Jplaystreamer, while minimserver now had 4 cpu affinity associated.
I double the multiplier to 1.6MHz to see if it helped but it didn't.Īfter this I moved back to 800Mhz and this time enabled hyperthreading. I have disabled hyperthreading on the i7 and this limited to only 4 logical cpu and also they were down clocked to run at 800Mhz. Found that I was using ProcessLasso which marked jplaystreamer as game & realtime process and cpu affinity to just one core out of the four. It eventually stopped but not as bad when playing from the control pc.Īfter this I wanted to see closely on my control pc. when minimserver was serving files from this 3rd pc, the arbitrary stop was not for every file but after several files being played. This pc is very low powered atom and its used as a a/v media server for my home network. Is there any hard requirement on the compute cpu resource needed for Jplay streamer ? I did some extensive experiments with another PC running just the minimsever. I think I have a hunch at this particular problem and might have a solution - I am running extended tests, playing continuous music before I update here. Its the issue with Minimserver that can't work with this setting or something is broken somewhere and I am trying to find out how is this particular application's behavior different from those others, like Foobar, JRiver, etc. All application that I am able to run on the control pc - Foobar, JRiver, BHE, Jplay mini - all of them works fine with this settings.
#MINIMSERVER CHANGE DRIVE DRIVERS#
Here I am not talking of the stability of a particular DAC link - in this case, I know for sure that the system is stable enough at a particular DAC link, which is in my case 170Hz/0.01s and the dac drivers well supports the fast refresh rate. Not all drivers supports the max link of 700Hz I know mine doesn't.
#MINIMSERVER CHANGE DRIVE DRIVER#
700Hz - I believe one of the biggest factor for supporting a particular DAC link is the DAC driver itself. That thread talks more of stability of a particular DAC link, for e.g. We are talking two different things as far as I can read but I maybe wrong. No, I believe they aren't identical (though apparently it appears that way). The only difference is that both MinimServer and foobar2000 (as well as JRMC20) cause the same issue (= an unexpected random stop and no automatic playback of the next track). Perhaps my following post would be relevant to this topic.
0 kommentar(er)
