Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foobar2000 1.3.8 beta discussion (Read 10941 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar2000 1.3.8 beta discussion

compiled with Microsoft Visual Studio 2013

goodbye, non-SSE2 processors 
QC, QA

foobar2000 1.3.8 beta discussion

Reply #2 –
Quote
Now compiled with Microsoft Visual Studio 2013.

Does it mean that min. OS requirement is XP SP3 now? If yes then IMHO it's a good idea to upgrade fb2k "System requirements".

foobar2000 1.3.8 beta discussion

Reply #3 –
Loading the streams/radios is super fast now, almost instantaneous.

foobar2000 1.3.8 beta discussion

Reply #4 –
New ReplayGain playback mode picking album/track gain depending on current playback order.

Great! I guess this makes foo_rg_trn obsolete?
It seems the replay gain mode changes for the next track, not immediately after changing playback mode. I found it to be a bit counter-intuitive, as I expected to hear a difference right after switching (minus the buffer delay)

foobar2000 1.3.8 beta discussion

Reply #5 –
Re non SSE2-
Looks like VS2013 defaults - even when importing from older VS - enable SSE without asking.
Fixed for the next update.
Microsoft Windows: We can't script here, this is bat country.

foobar2000 1.3.8 beta discussion

Reply #6 –
Quote from: lvqcl on
Quote
Now compiled with Microsoft Visual Studio 2013.

Does it mean that min. OS requirement is XP SP3 now? If yes then IMHO it's a good idea to upgrade fb2k "System requirements".

Perhaps. I tried to verify if things still work in Windows XP SP2 using VirtualBox and VMWare Workstation. It starts occasionally without trouble but other times the virtual machines die. VirtualBox just closes without error and VMWare turns into a tiny black window.

foobar2000 1.3.8 beta discussion

Reply #7 –
just drop support for XP. that would avoid any service pack confusion.

but seriously, people stuck on XP must know they should be running SP3. there is no reason not to.

foobar2000 1.3.8 beta discussion

Reply #8 –
I noticed that 1.3.8 b1 decodes FLAC and ALAC slightly slower than 1.3.7 (the difference in decoding speed is several percent). Maybe it's the result of Whole Program Optimization turned off.

foobar2000 1.3.8 beta discussion

Reply #9 –
I would like to vote against disabling the SSE2 optimizations.

Users with CPUs that do not support the SSE2 instructions (old Athlons) can always use an older version of foobar2000. The same applies to users that refuse to install SP3 on Windows XP.
On the other side everybody else (>99%) will benefit from the SSE2 optimizations.

So please enable the SSE2 optimizations again. Thank you

foobar2000 1.3.8 beta discussion

Reply #10 –
Quote from: Peter on
Fixed for the next update.

Thanks from me and my Athlons. By the way retrying dropped connections over HTTP is really long-expected feature.

to Euclid
don’t be so unfair 
QC, QA

foobar2000 1.3.8 beta discussion

Reply #11 –
About the new replay gain mode option.

Great for de different playback modes, but how about custom playlists you're playing in default mode?
If it's just albums you'd want to use the album value, but if you have a list with (seemingly) random tracks then the track value would be appropriate.

An idea, it might already be like this, but ...
While in default mode, to use the album value IF the previous OR next track IS from the same album.

Anyway, a nice addition to profit from fb2k's replay gain functionality.
Using the album value by default would most of the time be okay.

btw, love the added retry for streams, it was a bit awkward to have it constantly switch stations when on a bad connection.

foobar2000 1.3.8 beta discussion

Reply #12 –
Quote from: Euclid on
I would like to vote against disabling the SSE2 optimizations.

Users with CPUs that do not support the SSE2 instructions (old Athlons) can always use an older version of foobar2000. The same applies to users that refuse to install SP3 on Windows XP.
On the other side everybody else (>99%) will benefit from the SSE2 optimizations.

So please enable the SSE2 optimizations again. Thank you
+1 to that. Maybe make a legacy version that doesn't have them enabled, but there should be a limit to legacy support, really.
Old athlons are hardly usable nowadays (yes, I have some, and yes, I tried) and there is really no reason to stick with XP except on principle.

foobar2000 1.3.8 beta discussion

Reply #13 –
Quote from: Peter on
Re non SSE2-
Looks like VS2013 defaults - even when importing from older VS - enable SSE without asking.
Fixed for the next update.

My guess is that because in the upgrade process the option isn't actually changing ("Not Set" -> "Not Set") only now it means /arch:SSE2 instead of (the now added) /arch:IA32.  They probably want people to use it so that's why they have that behavior, I doubt it really matters for performance since the majority of the time you're just going to be playing back at 1x speed anyway.

Also please take a look at this[1].  I forgot to mention it in that post but the version of ffmpeg being shipped is old[2], the 2.4 branch is up to 2.4.7 now.

[1] http://www.hydrogenaud.io/forums/index.php?showtopic=108524
[2] https://www.ffmpeg.org/download.html#release_2.4

foobar2000 1.3.8 beta discussion

Reply #14 –
Quote from: lvqcl on
I noticed that 1.3.8 b1 decodes FLAC and ALAC slightly slower than 1.3.7 (the difference in decoding speed is several percent). Maybe it's the result of Whole Program Optimization turned off.

This is most interesting:

1.3.7 stable:
  ALAC: 324.123x realtime
  FLAC: 828.854x realtime

1.3.8 beta [SSE]
  ALAC: 308.505x realtime
  FLAC: 758.120x realtime

1.3.8 alpha [no SSE]
  ALAC: 307.728x realtime
  FLAC: 758.339x realtime


Whole program optimizations are enabled.
The offending optimizer feature (devirtualizing function calls):
* Was not available in VS2010 in first place
* Is not relevant to lowlevel decoding code (pure C), affects C++ only as far as I know
* The compiler switch that suppresses it - /d2notypeopt - isn't actually enabled for libFLAC code yet libFLAC turned up suspiciously slow also.

So, for some reason VS2010 build was faster. If we find no further advantages to using VS2013 compiler, we'll fall back.

Note that this doesn't affect formats that we handle through FFmpeg which is compiled externally with GCC.

Quote from: Euclid on
I would like to vote against disabling the SSE2 optimizations.

Users with CPUs that do not support the SSE2 instructions (old Athlons) can always use an older version of foobar2000. The same applies to users that refuse to install SP3 on Windows XP.
On the other side everybody else (>99%) will benefit from the SSE2 optimizations.

So please enable the SSE2 optimizations again. Thank you

I don't think you really understand what happened here.
foobar2000 has carried various SSE optimizations (also for newer SSE revisions) for a long time, enabled conditionally at run-time after checking for relevant CPU feature bits. Decoder libraries that we use - especially FFmpeg and libFLAC - already contain heavy optimizations for recent instruction sets. ReplayGain at >1000x realtime is only possible thanks to SSE2 code.

What happened is that while upgrading toolchain, whole foobar2000 was accidentally compiled with SSE instructions generated in place of legacy x87 opcodes for all floating point math, as the same compiler options turned out to have different meanings in different VS versions. But as you can see from the numbers I quoted above, this made no difference at all on decoding speeds (at least with these two formats). Once there are actual benefits to compiling everything with SSE enabled, we'll reconsider, but for now there are none.

Once the above speed issue is sorted out I can provide builds with different SSE modes enabled, then you can find out by yourself if anything actually gets faster from it.
You can also rebuild FFmpeg by yourself using the exact version I used but different configure line to get different SSE modes in it. The version I include with fb2k performs runtime CPU detection to enable the optimal mode.
Microsoft Windows: We can't script here, this is bat country.

foobar2000 1.3.8 beta discussion

Reply #15 –
Quote from: Peter on
So, for some reason VS2010 build was faster. If we find no further advantages to using VS2013 compiler, we'll fall back.


There are other advantages to using VS2013 such as improved buffer security checks and better global data optimizations[1] (this must be manually added to the command line but it shouldn't break anything AFAIK).  It is interesting that there is such an obvious performance regression.  I may try and profile it out of curiosity to see if there's an obvious spot which regresses but it is strange that two different libraries both have the similar performance regression.

Also lets not forgot we're still talking about something which is hundreds of times faster than realtime here so the perceived difference may be smaller than what the numbers may suggest.

[1] https://msdn.microsoft.com/en-us/library/dn305952.aspx

foobar2000 1.3.8 beta discussion

Reply #16 –
Update, ALAC can be made decode at speeds nearly equal to VS2010 output by tinkering with lowlevel options (intrinsics, inlining and so on).

However FLAC is a tough one, I cannot repro the slowdown testing stock FLAC.exe compiled with VS2010 vs VS2013, so there might be some other factors than just libFLAC code.
Microsoft Windows: We can't script here, this is bat country.

foobar2000 1.3.8 beta discussion

Reply #17 –
foobar2000 change log - version 1.3.8, states:
New ReplayGain playback mode picking album/track gain depending on current playback order.

Can someone elaborate on the above statement, or point me to documentation on exactly what is happening here? TIA

foobar2000 1.3.8 beta discussion

Reply #18 –
^ Download and install the current version in portable mode to see for yourself. You can simply delete the installation folder after.

foobar2000 1.3.8 beta discussion

Reply #19 –
Quote from: mville on
foobar2000 change log - version 1.3.8, states:
New ReplayGain playback mode picking album/track gain depending on current playback order.

Can someone elaborate on the above statement, or point me to documentation on exactly what is happening here? TIA
default+repeat mode -> auto set to album gain, any form of random -> auto set to track gain.

foobar2000 1.3.8 beta discussion

Reply #20 –
Thanks for confirming this. I wasn't able to look into that myself yet and it's a feature I've been missing.

Would it be possible to have it set the "Shuffle (albums)" mode to album gain, if it does not so already?

foobar2000 1.3.8 beta discussion

Reply #21 –
I think it already does (would make sense), but I haven't tested it.
Speaking of "shuffle (albums)", the issue I reported still persists with 1.3.8.

foobar2000 1.3.8 beta discussion

Reply #22 –
Quote from: ChronoSphere on
Quote from: mville on
foobar2000 change log - version 1.3.8, states:
New ReplayGain playback mode picking album/track gain depending on current playback order.

Can someone elaborate on the above statement, or point me to documentation on exactly what is happening here? TIA
default+repeat mode -> auto set to album gain, any form of random -> auto set to track gain.

It would be cool if it worked like the "intelligent" ReplayGain in Logitech Media Server. It will switch to track gain if adjacent tracks in the current play queue have different album gains and to album gain if they have the same album gain.

foobar2000 1.3.8 beta discussion

Reply #23 –
Quote from: Peter on
The offending optimizer feature (devirtualizing function calls):
*
*
* The compiler switch that suppresses it - /d2notypeopt - isn't actually enabled for libFLAC code yet libFLAC turned up suspiciously slow also.

If I understand what you're saying, the reason could be that the option is NOT set, so the (new offending) feature is NOT suppressed. Sorry if didn't.
In theory, there is no difference between theory and practice. In practice there is.

foobar2000 1.3.8 beta discussion

Reply #24 –
Quote from: GeSomeone on
If I understand what you're saying, the reason could be that the option is NOT set, so the (new offending) feature is NOT suppressed. Sorry if didn't.

You got it right.
However the VS2013 bug affecting foobar2000 is making our code crash or produce invalid results, not just slow down - relevant optimizer feature is meant to improve C++ code size & speed and does a good job at it when not confused by multi-DLL environment.
On top of that it affects C++ code only while libFLAC is pure C, hence the switch is meaningless for libFLAC - as far as I know.
Microsoft Windows: We can't script here, this is bat country.