Stephen Sinclair wrote:
> > asked about linus said "i know and i intend to keep it that
> > way" (paraphrasing).
>
> ah.
> i take it it's not a good idea then.. ;-)
> thanks for the answers, they were informative.
The other good thing about this is that once you give up
mem-mapping you can just
asked about linus said "i know and i intend to keep it that
way" (paraphrasing).
ah.
i take it it's not a good idea then.. ;-)
thanks for the answers, they were informative.
steve
On Thu, 13 Jul, 2006 at 04:45PM -0400, Stephen Sinclair spake thus:
> A thought occured to me recently...
>
> If I am writing an application which needs to stream a large wav file,
> I am having to write something which reserves some memory, and loads
> pieces of the wav file from disk on request.
Paul Davis wrote:
> LOL! that's pretty great. "not a fan" translates in real world terms
> into "one of LAD's most persistent critics of almost every aspect of C+
> +" :)) rock on erik, we love you anyway!
Aww shucks Paul. I'm blushing :-).
Maybe I should start pimping Ocaml here except that I w
On Fri, 2006-07-14 at 06:48 +1000, Erik de Castro Lopo wrote:
> but I am not a fan nor a great user of C++. The wrapper should
> really be written by someone with a love for the language.
LOL! that's pretty great. "not a fan" translates in real world terms
into "one of LAD's most persistent critic
On Fri, 2006-07-14 at 00:56 +0400, Dmitry Baikov wrote:
> If you need to stream a file, mmap'ed variant will eat memory up to
> file size. Given large enough file, it will eat all you memory and
> then will begin to page out unused portions of the file.
> Of course, details on when and where will v
If you need to stream a file, mmap'ed variant will eat memory up to
file size. Given large enough file, it will eat all you memory and
then will begin to page out unused portions of the file.
Of course, details on when and where will vary depending on VM-system
implementation.
The thing is, you r
Fons Adriaensen wrote:
> On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote:
>
> > I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with
> > few apparent methods (open/close, read/write frame(s)).
>
> Libsndsfile is plain C, but will do what you want without any
A thought occured to me recently...
If I am writing an application which needs to stream a large wav file,
I am having to write something which reserves some memory, and loads
pieces of the wav file from disk on request. Say I need to be able to
jump around the file a bit, I would have to detect
Hi James,
I am very interested in such a driver, but don't have a card to help you.
Will your driver work with Emu 1616M?
Best wishes,
Dmitry.
Dirk,
I'm afraid I have an appetite to work with long files also.
=== On Thursday 13 July 2006 23:11, Dirk Jagdmann wrote: ===
> Libsndsfile is plain C, but will do what you want without any fuss.
> You could write a WAV specific C++ wrapper on top of this in a few minutes.
libsndfile i
On Thu, 2006-07-13 at 21:11 +0200, Dirk Jagdmann wrote:
> > Libsndsfile is plain C, but will do what you want without any fuss.
> > You could write a WAV specific C++ wrapper on top of this in a few minutes.
>
> libsndfile is superb, but sometimes you don't want to link against
> external librar
Fons,
"in a few minutes" is true for *you* rather for me :-)
=== On Thursday 13 July 2006 22:07, Fons Adriaensen wrote: ===
On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote:
> I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with
> few apparent methods
Libsndsfile is plain C, but will do what you want without any fuss.
You could write a WAV specific C++ wrapper on top of this in a few minutes.
libsndfile is superb, but sometimes you don't want to link against
external libraries in your code. I have some structs/classes which I use
if in-memo
Dave Robillard wrote:
> Sorry, I /was/ referring to sem_post/sem_wait/etc. I mean havn't tried
OK :)
> Benchmarking message queues against pipes would be interesting, maybe
> Jack could benefit if they're faster?
I did some benchmarking between unix (local) sockets and message queues
and found
On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote:
> I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with
> few apparent methods (open/close, read/write frame(s)).
Libsndsfile is plain C, but will do what you want without any fuss.
You could write a WAV specif
I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with
few apparent methods (open/close, read/write frame(s)).
Suggestions?
On Wed, 2006-05-24 at 17:13 +0200, Maarten de Boer wrote:
> Hello,
>
> I am looking for a cross-platform implementation of an atomic
> integer.
>
> Under Linux, a build an c++ class "atomic" around asm/atomic.h,
> (which I can use as if it where an int), but I'd like to have a
> solution that als
On Wed, 2006-07-12 at 20:54 +0300, Jussi Laako wrote:
> Dave Robillard wrote:
> > realtime thread is pretty sketchy...). Pipes let you communicate
> > between processes though - I havn't tried the fancier POSIX interprocess
> > stuff yet.
>
> What do you mean by semaphore then, if not sem_*()?
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Jul 13, 2006 at 01:55:25AM +0200, Jens M Andreasen wrote:
> On Wed, 2006-07-12 at 23:43 +0200, jaromil wrote:
>
> > > i think mostly because in 2000-2001, they were very slow.
> >
> > IMHO they are still slow, especially when you port softwar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jul 12, 2006 at 05:56:00PM -0400, Lee Revell wrote:
> On Wed, 2006-07-12 at 23:43 +0200, jaromil wrote:
> > my solution so far is assuming that boolean is atomical.
> > all multi threaded handling i wrote is based on this assumption: i use
> >
Le 13 juil. 06 à 02:24, Stefan Westerfeld a écrit :
Hi!
On Wed, Jul 12, 2006 at 10:20:40AM +0200, Andy Wingo wrote:
On Wed, 2006-07-12 at 00:26 +0200, Stefan Westerfeld wrote:
I wrote a
little test which repeatedly switches between two threads, which
wakeup
eachother using a pipe, cond
22 matches
Mail list logo
