similar to: [PATCH 5/5] SIMD: remove outdated SSE2 code

This patch adds 2 new functions, FLAC__lpc_restore_signal_intrin_sse41() and FLAC__lpc_restore_signal_16_intrin_sse41(). The decoding speed of Subset-compatible 16-bit FLAC files is slightly increased on SSE4.1-compatible CPUs. -------------- next part -------------- A non-text attachment was scrubbed... Name: 04_add_new_intrin_func.patch Type: application/octet-stream Size: 9851 bytes Desc: not

Hi Guys, In stream_decoder.c when assigning lpc restore function, only IA32 processor benefits from SS2 and SSE4.1 optimization. Shouldn't it be the case for x86_64 processor as well ? Thanks, -- Olivier TRISTAN uvi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20140311/1d49b5c2/attachment.htm

On 9.3.2015 20:43, lvqcl wrote: > Janne Hyv?rinen wrote: > >> VLC 2.2.0 crashed with exception 0xc0000005 on the first file I tried. >> But libflac itself does not, for example flac.exe and foobar2000 have no >> issues. > *Very* interesting. > > I suspect that flac.exe and foobar2000 don't use > FLAC__lpc_restore_signal_16_intrin_sse2() function at all. This

Hi Guys, I know that FLAC format is currently limited to 8 channels but I was wondering if this hard limitation of the format or if it can be easily circumvented if the flac library is compiled with other settings and/or the software using it don't mind it Thanks ! -- Olivier Tristan Research & Development www.uvi.net

This patch accelerates decoding of non-Subset 24-bit FLAC files (where lpc_order > 12). (The improved function is FLAC__lpc_restore_signal_wide_intrin_sse41(). It requires SSE4.1 and it's used only by 32-bit libFLAC) -------------- next part -------------- A non-text attachment was scrubbed... Name: 03_wide_decode.patch Type: application/octet-stream Size: 5502 bytes Desc: not available

Erik de Castro Lopo wrote: > Sorry, this patch fails to apply on top of the others. Would > you be able to rebase against what's currently in the tree? Ok, will do it, but currently xiph git still contains old code.

I see :( That what I would call a good struct size optimisation. Please tell me there was another reason behind this being only 3 instead of 8 or 16 bits, right ? 2017-01-25 18:30 GMT+01:00 Tor-Einar Jarnbjo <tor-einar at jarnbjo.name>: > Hello Olivier, > > the limitation is in the file format itself, as the number of channels is > encoded in a 3 bit field in the streaminfo

Op 03-12-14 om 16:48 schreef Olivier Tristan: > Looks like I've missed the talk about this regression introduced in 1.3.1.

More specifically, about this patch: http://git.xiph.org/?p=flac.git;a=commitdiff;h=70b078cfd5f9d4b0692c33f018cac3c652b14f90 I downloaded the latest code from git (flac-70b078c), disabled all SSE optimizations in the code and compiled it (GCC 4.8.2). This patch doesn't change FLAC output. Either gcc is too smart and optimizes this new code back to the old, or this fix is MSVS-specific. Or

Don't overlook the FLAC in Ogg container solution. That's established as a standard for some time now, as far as I know, and would probably be better than a new, proprietary multi mono bundle. I haven't used it myself, but people have been talking about it for a while, and I believe that some "FLAC" users are actually working with FLAC in Ogg container files. Brian

Is it possible to see the source code of the open-sourced SVML? The diff file does not include the library. I searched the Internet but I could not find. Regards, Naoki Shibata On 2016/07/15 13:55, Tian, Xinmin wrote: > Naoki, > > Intel is planning open-source SVML library (most of them if it not 100%), 6 functions of SVML are open sourced for GCC and LLVM already. But, Intel SVML

Hi Guys, The current trunk do not build with GCC 4.2 on OSX when compiling cpu.c <cpuid.h> does not exists and __get_cpuid() is not defined This version of GCC is required if you want to support pre 10.7 systems which are still pretty common. It seems other project had the same issue https://bugzilla.mozilla.org/show_bug.cgi?id=836824 Don't know much what would be the right fix.

Hi Guys, I've just faced a wrong warning trying to encode a 24 bits WAV file if(wFormatTag == 1) { if(bps != 8 && bps != 16) { if(bps == 24 || bps == 32) { /* let these slide with a warning since they're unambiguous */ flac__utils_printf(stderr, 1, "%s: WARNING: legacy WAVE file has

Hi Guys, Does having multiple apodization functions change something to the decoding process or does it only apply to the encoding process ? I have been able to gain almost 10% by using several apodization functions (it takes way more time to encode but this is quite a non issue in my use case) but I don't want to sacrifice any decoding speed as this is the bottleneck for me. Thanks,

Hi Guys, The following code in CPU.c (line 155) won't link if you don't have NASM code built even if FLAC__HAS_X86INTRIN is true as FLAC__cpu_info_asm_ia32 don't exists and the else is compiled if there is no dead code stripping if (FLAC__HAS_X86INTRIN) { FLAC__cpu_info_x86(0, &flags_eax, &flags_ebx, &flags_ecx, &flags_edx); info->ia32.intel =

Federico Miyara wrote: ... > The file format allows some unused fields for future use, such as the > padding block. It could include a flag to indicate a change in the > format adding one more streaminfo byte which would allow up to 256 > channels (actually, 256 + 8), or it could trigger a new byte when 11111111. > > There is also an invalid block identifier (127) which could be

On 9.3.2015 19:06, lvqcl wrote: > Tristan Matthews wrote: > >> Hi, >> >> VLC recently migrated to libflac 1.3.1, however we had to revert to >> 1.3.0 as we had crashes for most FLAC files on the Windows desktop >> platform. >> >> More information is available here: >> https://trac.videolan.org/vlc/ticket/14104 > Cannot reproduce the crash

Hi all, Okay, the point is whether Intel will publish the source code for their SVML. If Intel will make SVML open-source, there would be not much advantage in incorporating SLEEF into LLVM, since it would be also fairly easy to port SVML to other architectures. If Intel will not open-source SVML, then there could be advantage in using SLEEF for x86 by inlining the functions. Is it possible

Op 03-12-14 om 15:49 schreef Olivier Tristan: > [...] > If you want to check this on a single piano note, I would be > happy to know if this improves the monophonic use case as well. This sample is indeed a case where the retuning of FLAC 1.3.1 shows a severe regression. It seems the patch does work quite well in this case, but it does not fully fix the regression. FLAC 1.3.0 -5:

On Mon, Mar 9, 2015 at 5:15 PM, lvqcl <lvqcl.mail at gmail.com> wrote: > Janne Hyv?rinen wrote: > >> I compiled flac.exe without NASM and verified that >> FLAC__lpc_restore_signal_16_intrin_sse2 is used. Decoding the same file >> that made VLC 2.2 crash decoded without issues. Would be nice if VLC was >> compilable with MSVC and we could use its debugger.