Up to the posting of the your code , all we have is your description of the problem and your interpretation of the behaviour. So all we can do is offer places to look where things are different. That said my comment are my interpretation of siutation coming from a LMS POV and so are also biased.
A pcap dump of the network conversation between your servers and player would enable the exchange to be analysed and compared to LMS to see if there is anything unusual or different (e.g jumbo frames). TCP is a streaming protocol but that the flow of data can be lumpy or smooth depending on data handling I am well aware your system has worked for many years on a Pi - so I'm trying to think what is different from a network and computing POV. * between Squeezelite (e.g. Linux based) & older IPK players such as Classic. * between Pi and NUC * between your system and LMS Squeezelite vs Classic - main difference is larger buffers. There are types of internal player buffer: received data and decoded data. IIRC With Classic Data is first put into received data buffer but not acknowledged until audio is moved into decoded buffer (i.e. ready to play) so TCP windows edge is moved when audio is played and space is made in decoded buffer. With Linux based players , data is acknowledged as it is received and put unto internal buffer. Linux based players also have unacknowledged data which are kept in Linux network buffers. So sending data after TCP window edge movement is critical to smooth playing on Classic but not so critical on Linux based players all the more so with Classic smaller buffers. Pi vs NUC - I'm guessing Pi is a Pi1 or 2. PI1 had only 1 core but Pi2,3&4 and Intel Celeron all have 4 cores. If Pi1 was used then 1 core is significant. NUC is a lot faster and NUC has a more advanced & faster network chip. All this adds up to "timing" probably underlying issue. On Pi your system was probably more "linear" as it was slower, use Blocking and more task by software. NUC will be faster and so behaviour may be more in parallel. There may be have been a latent issue here. On LMS a stuttering issue showed up on Windows system (mainly high end and low end) - turned out to be bug in event handling (e.g write compete, read ready ) which had been in LMS for many years but only showed up with newer faster x86 systems and more than 4 cores. Newer network hardware may have resulted in changed network options. Your system & LMS - Not enough info regarding protocol implementation in case slimproto frames are used differently or in different order and how network connection is set up (e.g. TCP options) . Only thing that can be seen is using Blocking vs Non blocking I/O. Blocking is more linear whereas non-blocking is better able to handle tasks in parallel - this is an observation. I think to solve this problem, I think a pcap dump is essential if only to eliminate a class of possible problems. It will also show what is happening and what is going wrong and possibly work backward to source of the problem using the why.csv data. At them moment I am comparing why.csv with an LMS equivalent to see if buffer filling/transmission "behaviour" is different/similar. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=110986 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
