Subjective comparison of Software Music Player

[seeteeyou]

Awesome comparisons among so many candidates, thanks a lot for taking the time.

 

So far wtfplay seemed to be the champion and there's another comparison as follows

 

https://audiophilestyle.com/forums/topic/24966-ecdesigns/page/23/?tab=comments#comment-1070708

 

Just wondering if SqueezeCore + LMS were able to rival wtfplay by any chance?

 

https://audiophilestyle.com/forums/topic/58398-squeezecore-a-minimal-audio-os-running-squeezelite/

https://audiodigitale.eu/?p=228

Quote

I built SqueezeCore because I needed a lightweight, minimal, plug&play OS to use it as a squeezelite player. The whole OS is 17MB and when running it occupies around 60MB of RAM; SqueezeCore must be installed on a USB drive and will run completely in RAM.

 

[seeteeyou]

On 9/19/2020 at 4:20 PM, manueljenkin said:

Thank you for the kind words and the links. Unfortunately my experience stops here. I am yet to try any networked audio chain or signal regenerator. If I ever come across and make a post/comparison, I'll tag you. The sdtrans384 is something I'm interested to get when I have the budget.

 

Maybe you could compile this playhrt.c program first, then try it with SqueezeCore without having to enable networking at all?

 

Available here and it's written in C

 

http://frankl.luebecknet.de/stereoutils/player.html

http://frankl.luebecknet.de/stereoutils/frankl_stereo-0.7.tar.gz

https://bitbucket.org/frank_l/frankl_stereo/src/master/src/playhrt.c

 

A further optimized version was posted here (Google Translate)

 

https://www.aktives-hoeren.de/viewtopic.php?p=190192#p190192

 

Feedback seemed to be quite positive (Google Translate)

 

https://www.aktives-hoeren.de/viewtopic.php?p=190544#p190544

Quote

... und nach einer weiteren Woche kommt von mir folgendes, anwenderbezogene Feedback:

 

Playhrt war für mich der bevorzugte Player, seit ihn Frank veröffentlichte. Ich verwende playhrt, weil playhrt ein Player ist, der nichts anderes macht, als das abzuspielen, womit er gefüttert wird. Und das erwarte ich von einem Player, und nichts mehr.

 

Aber playhrt es war ein störrischer, zickiger Player, welcher einiges an Konfigurationsaufwand abverlangte, und zum Teil auch einige Workarounds mittels erweitertem scripting notwendig machte. Ich musste zum Beispiel, wie schon mal beschrieben, die clocks meiner RME Soundkarten nachtunen, damit playhrt trotz händisch sorgfältig eingestellter --extra-bytes-per-second weder über-, noch unterlief. Und die Geschichte mit dem handsärmeligen --sleep half auch nicht immer weiter, weswegen ich, doppelt gemoppelt, playhrt noch einen writeloop-catloop-Puffer vorschaltete. Und trotz all diesem Unbill blieb playhrt in meinen pipes. Weil es ein präziser Player ist, der nichts anderes macht, als das, was er sollte. Ceterum censeo ...

 

Wenn ein Setup mit playhrt mal nicht lief, was durchaus des öfteren vorkam, dann musste wieder aplay auf die Bühne. Denn aplay frisst fast alles und frickelt im Stillen, vom User meist unbemerkt, mit grosser Wahrscheinlichkeit etwas daraus, was dann auch der Soundkarte bekommt ... Aplay ist wesentlich permissiver als playhrt, ist dafür jedoch in Bezug auf das dem Audiostream aufgebrachte DSP eine verschwiegene blackbox. Und aplay spuckte nebenbei auch wertvolle infos zum Debugging aus, welche es unter Anweisung mittels --verbose und --dump-hw-params preisgab. Aber als standard-player? Nein danke. Zu viel stilles, unkontollierbares Eigenleben.

 

Und nun, nach diesem Exkurs zu aplay - was ist nun mit playhrt nach einer Woche? Sagen wir es mal so: Ich habe seither aplay nicht mehr gebraucht.

 

Playhrt war, wie schon erwähnt, der prinzipiell schlanke und präzise Player, den ich mir wünsche. Und meines Wissens ist es der präziseste Player, den es für Linux gibt. Jetzt ist playhrt noch schlanker geworden. Und zwei der früher notwendigen, empirisch zu ermittelnden Parameter, --sleep und --extra-bytes-per-second, sind durch die Implementation interner Algorithmen hinfällig geworden. Und damit ist playhrt sogar anwenderfreundlich geworden.

 

Als einzig potenziell kritischer und empirisch zu ermittelnder Parameter ist --loops-per-second (LPS) geblieben. Ich hatte bislang den Eindruck, dass LPS nicht beliebig deklariert werden konnte, sondern in Abhängigkeit der Rate und der Anzahl Ausgangskanäle gesetzt werden musste. Dabei scheint es günstig zu sein, wenn in einem 2-Kanal-System der Quotient Rate/LPS Werte von 2^n ergibt. Das heisst, bei einer Rate von 44.1kHz stelle ich die LPS vorzugsweise auf 1050 ein, bei einer solchen von 48kHz stelle ich die LPS=1500 ein. Aktuell, auf einem 8-Kanal-System bei 96kHz habe ich LPS=6000 eingestellt.

 

Fazit: Merci viumau, Frank u Andree

 

---

 

Another ASIO WAV player for Windows here and it's called PlayWave, it could be combined with various versions of MinorityClean etc.

 

http://www.myav.com.tw/bbs/showthread.php?threadid=20459807&perpage=12&pagenumber=19

 

PlayWaveVC64Cache_20200818

https://www.dropbox.com/s/35j3l1vbbf47pzi/PlayWaveVC64Cache_20200818.rar?dl=0

 

Singxer F-1 libusbK driver

https://www.dropbox.com/s/kimi5bacn53dbmw/USB_Audio_2_0_F1_physical_align_page_20200818.rar?dl=0

 

Musiland Digital Times 2 libusbK driver

https://www.dropbox.com/s/wajqrpfvnz7w70n/Digital_Times_2_Interface_0_physical_align_page_20200818.rar?dl=0

[seeteeyou]

I saw 19041.1 on the other thread you just started several hours ago, then I recalled something about the "bare minimum" version of that particular Windows build number

 

ReMin - replicated MinWin
https://github.com/replisys/remin-core

 

Remin project notes
https://osg.wiki/books/servicing/page/remin-project-notes

 

FYI - I did a search on Google and found the specific ISO required for ReMin, though it would take quite a few tries to start downloading the file successfully

 

https://pastebin.com/raw/iMGaaCYJ

 

After that, some packages should be necessary for adding audio support back to the OS

 

https://uupdump.net/findfiles.php?id=c8e87bb7-e741-41c1-b164-d97a56d9fd49

 

Someone posted some instructions here

 

https://forums.mydigitallife.net/threads/guide-adding-gui-to-server-core-1-21v.76023/page-9#post-1412792

 

And then this one could also be useful

 

https://cloud.mail.ru/public/qRL8/5ijBydZDU/Packs/MultimediaRestrictedCodecs/10.0.19041/

http://forum.notebookreview.com/threads/help-debloating-windows-10-image-needed.832141/

Quote

+ Updated the Feature "Integrate Multimedia Restricted Codecs" to support Windows Server v2004 Source OS.

 

[seeteeyou]

http://jplay.eu/forum/index.php?/topic/4410-windows-11-pe-audiophile-creation-guide/?p=57836

Quote

Win10XPE is VERY SUPERIOR TO WTFPlay.

 

http://jplay.eu/forum/index.php?/topic/4410-windows-11-pe-audiophile-creation-guide/?p=57778

Quote

Still, the SQ impact of killing lsass.exe back then and now is VERY noticeable, and I would not necessarily say it is always good… you reach a very high level of detail and transparency, but god help you if you’re listening to a poorly recorded track, as everything will be shown in excruciating detail, warts and all. It also can cause even good recordings to sound harsh. Anyway, play with this at your own risk both SQ-wise and functionality-wise, but if you killed lsass.exe, the two svchost instances for AudioSrv and AudioEndpointBuilder, AND the instance for CryptSvc, as well as killing shell processes and the other processes I've detailed earlier in this post, you would be left with a whopping low of 14 processes running!

 

Quote

The SQ boost is just amazing in WinPE. It is, hands down, the biggest audio OS-based boost in SQ I have ever experienced with any solution, and I have tried quite a few beyond RAMdisk. The clarity is really, really something, just insane amounts of detail retrieval and noise floor reduction.

 

http://jplay.eu/forum/index.php?/topic/4410-windows-11-pe-audiophile-creation-guide/?p=57899

Quote

If you did all this it would be down to 12 processes, ha! Could be too much, but only one way to find out, I suppose…