On Thu, Jul 7, 2011 at 9:38 AM, Dan Muresan danm...@gmail.com wrote:
[ ... ]
Dan - I'm really confused by what you're getting at, or trying to get
to. It seems as though you think there is a difference in the
throughput when you read from a filesystem using st_blksize or some
other size close
OK. If you look back, this whole round of discussions was a
consequence of me saying VIO in sndfile is ALSO good because I
didn't think it was really such a big deal in the first place: VIO is
already there, and I was able to accomplish my programming goals.
1) there's a reason to use
non-st_blksize sized blocks will be absolutley swamped, by disk
latencies, cache latencies, scheduling latencies and file
decoding overhead.
your measurements would be so swamped with noise from other
factors that any differences would be statistically irrelevant.
If you could explain how
Dan Muresan wrote:
non-st_blksize sized blocks will be absolutley swamped, by disk
latencies, cache latencies, scheduling latencies and file
decoding overhead.
your measurements would be so swamped with noise from other
factors that any differences would be statistically irrelevant.
Regardless of whether you choose to measure latency or CPU load
if you vary the st_blksize as specified in the previous email,
you will not be able distinguish between the two values of
st_blksize due to the influence of other factors.
What are you talking about? How can one vary st_blksize
Dan Muresan wrote:
Regardless of whether you choose to measure latency or CPU load
if you vary the st_blksize as specified in the previous email,
you will not be able distinguish between the two values of
st_blksize due to the influence of other factors.
What are you talking about? How
I never much liked the VIO layer. It was only ever added because
a large number of people requested it. I think its fragile and
it exposes too much of libsndfile internals to the user.
There is one remaining issue that I have discovered while writing
jack-file, and which can only be
Dan Muresan wrote:
I never much liked the VIO layer. It was only ever added because
a large number of people requested it. I think its fragile and
it exposes too much of libsndfile internals to the user.
There is one remaining issue that I have discovered while writing
jack-file, and
I haven't measured it, but my educated guess is that if you're
reading 16384 frames at a time from a FLAC file on current hardware,
then the difference between reading st_blksize sized blocks and
Uh, actually no. If one reads 4096, 2048, or 1024 frames the result is
the same -- 4 bytes less
Dan Muresan wrote:
I haven't measured it, but my educated guess is that if you're
reading 16384 frames at a time from a FLAC file on current hardware,
then the difference between reading st_blksize sized blocks and
Uh, actually no. If one reads 4096, 2048, or 1024 frames the result is
does libsndfile ever clear the error flag on a file? E.g. if there is
a decoding error in a FLAC, and I sf_seek() back to the beginning,
will sf_read_() work normally again?
Maybe not on FLAC. I would suggest that you write a small
standalone test program to test this and if you don't
Dan Muresan wrote:
does libsndfile ever clear the error flag on a file? E.g. if there is
a decoding error in a FLAC, and I sf_seek() back to the beginning,
will sf_read_() work normally again?
Maybe not on FLAC. I would suggest that you write a small
standalone test program to test
You need to supply me with a small test program and if necessary
this broken FLAC file.
1. Rather hard to do at the moment -- not the least because the
brokenness is injected via the vio layer.
2. Why? This was not a bug report. This was an API *clarification
request*. sndfile doesn't claim to
Dan Muresan wrote:
You need to supply me with a small test program and if necessary
this broken FLAC file.
1. Rather hard to do at the moment -- not the least because the
brokenness is injected via the vio layer.
I never much liked the VIO layer. It was only ever added because
a large
I never much liked the VIO layer. It was only ever added because
a large number of people requested it. I think its fragile and
it exposes too much of libsndfile internals to the user.
Well, it doesn't seem to expose anything other than the set of chosen
functions (read / write / seek etc) --
Dan Muresan wrote:
I never much liked the VIO layer. It was only ever added because
a large number of people requested it. I think its fragile and
it exposes too much of libsndfile internals to the user.
Well, it doesn't seem to expose anything other than the set of chosen
functions
Hi,
does libsndfile ever clear the error flag on a file? E.g. if there is
a decoding error in a FLAC, and I sf_seek() back to the beginning,
will sf_read_() work normally again?
Or, if a premature EOF is reached, will seeking back somewhere in the
file allow playback to resume? libsndfile claims
Dan Muresan wrote:
Hi,
does libsndfile ever clear the error flag on a file? E.g. if there is
a decoding error in a FLAC, and I sf_seek() back to the beginning,
will sf_read_() work normally again?
Maybe not on FLAC. I would suggest that you write a small
standalone test program to test
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
Dan Muresan wrote:
Hi Erik -- please CC me so I can reply (I don't receive messages from
LAU directly). I'm quoting manually here:
I'm trying to cancel an ongoing sf_* I/O operation (from another
Maybe its a bad idea. :-)
I don't think so... Issuing large requests, then cancelling as
29 matches
Mail list logo
