To me that suggests that either you have a completely unique
problem to solve or that they are other solutions to your
problem that other people use to get around the same problem.
My guess is that your problem is not completely unique.
Certainly not unique. My guess is that nobody worried
Dan Muresan wrote:
Certainly not unique. My guess is that nobody worried about a
(possibly small) performance penalty, and instead used simpler
strategies -- or they weren't using sndfile in the first place.
Consider this: for any request size you choose, NOT cancelling could
double your
Err, if you're worried about latency, why are you streaming from
a slow NFS server?
The point was that NOT cancelling introduces extra latency
unnecessarily, and short requests introduce CPU overhead. I gave the
NFS example to preempt the hard disks are really fast objection that
some people
b) Work around it.
This is what I was trying to do via pthread_cancel + sf_open_fd. It
seems to work with FLAC.
However, there could be memory leaks if any decoder / encoder function
(in sndfile or one of the external libs) allocates temporary memory
that it expects to free before returning.
Dan Muresan wrote:
b) Work around it.
This is what I was trying to do via pthread_cancel + sf_open_fd. It
seems to work with FLAC.
However, there could be memory leaks if any decoder / encoder function
(in sndfile or one of the external libs) allocates temporary memory
that it expects
On Tue, Jun 14, 2011 at 01:01:09PM +0300, Dan Muresan wrote:
b) Work around it.
This is what I was trying to do via pthread_cancel + sf_open_fd. It
seems to work with FLAC.
'Work around it' coild mean something entirely different : not
trying to cancel anything, by using a system that
Hi Fons,
It's probably a Good Thing (TM) that libsndfile doesn't do its
own buffering. First, the file system will do buffering, and if
I agree, I prefer the flexibility of implementing my own user-space
cache in an app-dependent way, too.
exactly this is organised will be application
that it expects to free before returning. Do you know if this might be
the case (e.g. for the native formats, libFLAC, libvorbis)?
No idea. I would be surpised if this works.
It seems to works for FLAC, but I can't trust it either. Besides
memory leaks, mutexes might remain locked, and
On Tue, Jun 14, 2011 at 02:42:18PM +0300, Dan Muresan wrote:
For sure, two user-space caches add a useless extra layer of copying.
Not only copying (which is cheap anyway), but also logic.
Your application layer cache knows what you want to achieve,
will have some ad-hoc strategies and try to
The intermediate one doesn't have that and may well work against
you. The same problem exists with the system level buffering,
Yes. Well, the worse clash is between the kernel-space vs. the
user-space caching strategy, but indeed you can't do much about it
(unless you go the O_DIRECT way like
Hello all,
Some updates now available at
http://kokkinizita.linuxaudio.org:/linuxaudio/downloads
zita-rev1-0.2.1
* Nasty bug detected and fixed by Robin Gareus (thanks !)
zita-rev1-0.2.1 and zita-at1-0.2.2
* Changed looks at bit (rotary knobs look different).
* Added -pthread to linker
On 06/15/2011 12:26 AM, Fons Adriaensen wrote:
Hello all,
Some updates now available at
http://kokkinizita.linuxaudio.org:/linuxaudio/downloads
yay. yummy software updates :)
zita-rev1-0.2.1
zita-rev1-0.2.1 and zita-at1-0.2.2
it seems that, despite the ending .bz2, both files are
12 matches
Mail list logo
