similar to: Proof-of-concept multithreaded FLAC encoder

Frederick, This is great news! Thanks for your effort. Your proof-of-concept raises a few questions for me: 1) I know that the ratio of uncompressed to compressed data is unpredictable, but I never really considered whether the input block size or the output block size is constant. I'm assuming that if you're breaking the uncompressed input file into multiple pieces, then the

Hey again FLAC devs, I managed to hack out another proof-of-concept multithreaded FLAC encoder that is more amenable to streaming and also uses a fixed buffer size. The performance is pretty much the same as my earlier version; that is, I can encode a 636 MB wave file in ~7s with 8 threads on an 8-core 2.8 GHz Xeon (I erroneously stated 3.0 GHz in my last e-mail) vs ~32s with 1 thread. I had

On Tue, May 6, 2008 at 2:03 PM, Brian Willoughby <brianw at sounds.wa.com> wrote: > Frederick, > > This is great news! Thanks for your effort. > > Your proof-of-concept raises a few questions for me: > > 1) I know that the ratio of uncompressed to compressed data is > unpredictable, but I never really considered whether the input block size or > the output

On May 6, 2008, at 14:20, Frederick Akalin wrote: > On Tue, May 6, 2008 at 2:03 PM, Brian Willoughby > <brianw at sounds.wa.com> wrote: >> 3) Do you accelerate decode as well as encode? I'm thinking that >> the >> variable block size would require each thread to scan its block >> for the >> start of a new block header, and also continue

Along the same line as Frederick, myself and another university student were able to implement a multi threaded FLAC encoder, but using Intel's Threading Building Blocks (TBB) package. We saw similar near-linear speedup. Our solution is a bit more convoluted since we were learning the API, TBB and writing the encoder all in one 6 week period. We used a pipeline model on the input stream, and

On Tue, May 6, 2008 at 4:52 PM, Christopher Peplin <chris.peplin at rhubarbtech.com> wrote: > Along the same line as Frederick, myself and another university student were able to implement a multi threaded FLAC > encoder, but using Intel's Threading Building Blocks (TBB) package. We saw similar near-linear speedup. Great! Your approach is better in that it bounds the memory

--- Harry Sack <tranzedude@gmail.com> wrote: > 2007/9/8, Josh Coalson <xflac@yahoo.com>: > > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers

On Sat, 15 Jun 2019 at 01:24, Abby Spurdle <spurdle.a at gmail.com> wrote: > > None of the tools that I've looked at satisfy these constraints. > But if you know of some, I'd like to know... And I would consider contributing... What about Atom, VS Code and the like? Or what about taking a project that meets most of the constraints and pushing to cover all of them, or even

2007/9/9, Josh Coalson <xflac@yahoo.com>: > > --- Harry Sack <tranzedude@gmail.com> wrote: > > 2007/9/8, Josh Coalson <xflac@yahoo.com>: > > > > > > it actually is complicated. the libFLAC api is not suited to a > > > multithreaded design because the i/o is stream-based, not file- > > > based. flac(.exe) is the file-based wrapper

Have you tried decoding to memory, and encoding from that memory? This technique would avoid file I/O. If you are reluctant to allocate enough memory for the full file (and why not, with a 64-bit system?), then you could implement a FIFO. You would need a semaphore to keep track of the decoder's progress, and multithreaded coding. The decoder would pause, whenever the FIFO gets

Hi. We have a configuration and audit application called Tripwire Enterprise (7.5) that is running on a Red Enterprise Linux 5.2 server. On this server, we are using winbind (samba version 3.0.33) for authentication (against Windows AD). When we try to run a configuration check on users and permissions we get an error that there is a problematic frame : C [libnss_winbind.so.2+0x129f] . I

I'm not aware of any other attempts, and there have never been official plans. It's difficult to partition input for opus at anything other than the track level, because of the way the decoder derives its adaptive state from recently-seen audio. I guess cutting together streams with at least an 80ms overlap wouldn't glitch too much? You could probably do something to try different

>>> Ralph Giles <giles at thaumas.net> schrieb am 30.03.2020 um 23:17 in Nachricht <11930_1585603054_5E8261ED_11930_50_1_c110a52d-de95-3bbb-35b2-eca12c79f143 at thaum s.net>: > I'm not aware of any other attempts, and there have never been official > plans. It's difficult to partition input for opus at anything other than > the track level, because of the way

Thanks for the tip, Brian. I did have a version that does everything in memory, but only had enough memory to get six threads going. (Although my system has 16GB, I have not taken the time to create 64-bit libraries for wxWidgets, TagLib, libFLAC, etc.) Based on the direction you are pointing me in, I assume that encoding from within the decoder is not permitted. I really like your idea of the

On Tue, Feb 3, 2009 at 12:33 PM, aparna kotha <kotha.aparna at gmail.com> wrote: > Hi all: > > I am working on a project using llvm and we need to deal with multithreaded > applications. I wanted to know if there was a C front end for llvm that > could parse multithreaded applications? I tried llvm-gcc (4.2) and could not > get it to work. Is there an extra parameter that I

I am interested in being able to encode a single Opus stream using several CPU cores. I get a raw audio input and "opusenc" can transcode it at 1200% speed (Raspberry PI 3B+). It saturates a single CPU core, but the other three are idle. Is out there any project to add multithreading options to "opusenc", or something in that line? Looking around, I have found this:

Hi, In fact I have some theory on instruction level parallelism( i have a partitioning algorithm), then first of all, i want to generate a multithreaded code from LLVM IR (in assembly level) with a given partitioning. My problem is how can i use a thread library(like Pthread) or OS system calls in LLVM IR to create and manage threads? --- On Tue, 10/5/10, Tobias Grosser <grosser at

I am using pthreads. I was also wondering what will the llvm IR be for pthreads ? On Tue, Feb 3, 2009 at 3:51 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Tue, Feb 3, 2009 at 12:33 PM, aparna kotha <kotha.aparna at gmail.com> > wrote: > > Hi all: > > > > I am working on a project using llvm and we need to deal with > multithreaded > >

Harry, You assume that the only way to use FLAC is the way that you are using it, by converting one file format to another. That's not the only way to use FLAC. The most important uses of FLAC are for internet streaming radio or hand-held digital audio players. Both of these prominent uses are not really file based, but are stream based. It makes perfect sense for the core of

I noticed that the statically linked ogg/vorbis libraries for Windows are multithreaded. I want to link them into a non-multithreaded application, so I'm considering recompiling them to use the non-multithreaded C runtime. Is this feasible, or do libogg and libvorbis rely on multithreading? <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: