It occurs to me that this information may not be helpful. The 3900X could be 10X slower but still spend the same percentage of time in the same loops. Is there a way to quantify the actual number of instructions or the amount of time to execute an instruction using this profiler?
You would need a lower level profiler (or at least I don't think VS can do it but I could be wrong) like Intel's Vtune or AMD's CodeXL. The problem with that is that you'd have to use each vendor's tool (most likely) since you want access to low level timing information and hardware counters.
However, your profiling above says that essentially the entire runtime is spent in that one bit of hand written MMX. Unfortunately since it looks like the linker inlines, you're not able to see finer detail. Have you tried profiling the version with MMX disabled and just letting the compiler generate its own code?
Is that what the numbers next to the percentages show? For example, the 18,656 next to the pack_decorr_stereo_pass_cont_common: Is that the number of times that particular loop executed in the 30.685 seconds of profiling (i.e., 608 per second)?
That is the number of milliseconds spent in that function and anything it calls.
Last post by TheQwertiest -
PS: the version is called "preview", because it was built manually on my PC (instead of appveyor CI as before). Because of Microsoft shenanigans this is the only way right now. It will be republished as a proper non-preview version once MS fixes the bug (mind you, it's already been two months since the bug was reported). It will be the same though functionality-wise (unless there are bugs discovered, of course)
Last post by Porcus -
End of track, just before it switches. (Easy to check, just have FLAC up next.) Wasapi-push with RG.
I thought it was the foo_verifier, as it started becoming over-zealous. But even when uninstalling that, it also happens at the end of "any" mp3 playback.
Last post by sveakul -
Strange, not seeing that here. In Playback/Output I'm using wasapi-event with buffer length set at 610ms, no RG, cursor follows playback. Read-ahead set to 0 for local files, no full track buffering. Are you seeing the pop-up as soon as playback begins or towards the end of the track?
Last post by sveakul -
I had been using Spider Monkey Panel to write a simple playing track history log file; while it works brilliantly it is overkill in both size and functionality for my own basic needs. I stumbled upon the foo_np_simple (Now Playing Simple) plugin from Skipy Rich today (http://skipyrich.com/wiki/Foobar2000:Now_Playing_Simple) and found it could do all I wanted at a minimal size, and the latest 1.9.1 version works fine with Foobar 1.5 Beta 13. I have only "On New Track" checked in the Events drop-down, and options formatted as shown here (I left some default code in that wasn't interfering with anything):
This produces a text file output of tracks played (e.g., from radio streams) as shown here:
[Wed Sep 11 16:49:21 2019]: Prog Rock - Aural Moon: The Net's Progressive Rock Garden [Wed Sep 11 16:49:21 2019]: Genesis - Home by the Sea [Wed Sep 11 16:49:32 2019]: Russian - Glavnoe Radio 104,8 FM [Wed Sep 11 16:49:32 2019]: Машина времени - Он был старше её [Wed Sep 11 16:49:44 2019]: Gothic/Metal (Radio Caprice) - Radio Caprice - Female Vocal In Metal [Wed Sep 11 16:49:44 2019]: Acid King - Heavy Load [Wed Sep 11 16:49:49 2019]: Gothic - WildCat -- Gothique [Wed Sep 11 16:49:49 2019]: Alight - The Portal [Wed Sep 11 16:49:56 2019]: New Age - ESOTERICA.FM NEW AGE BRASIL [Wed Sep 11 16:49:58 2019]: Oliver Shanti - Era Limited Edition - Sacral Nirvana (Radio Edit)
My question is, is there a function/script/code entry I can add that would set a max limit of entries before beginning to delete the earliest played track? Thanks for any help!
Last post by kbo -
Kodi (www.kodi.tv) has the same problem with the latest YT v6.5.1 plugin - "no streams found". I guess all YT plugins for all applications need updating
I think foobar waits too long, too close to the end of the track, before it starts to buffer the next track
It doesn't wait anything. If you set buffer size 10 s it will begin to decode next track when 10 s are remaining to the end of current track; if you set buffer size 30 s it will begin to decode next track when 30 s are remaining to the end of current track. Also, in 1.4 there was additional option introduced in advanced preferences - Advanced->Playback->Buffering->Read ahead for local files (kB).
