16 Sep
2012
16 Sep
'12
9:46 a.m.
Hi,
Over the week or so, I've build some fuse filesystem filters flac files
on-the-fly
using the zita convolver. This makes it real easy to play
around with files and filters. In particular with systems that otherwise
don't support stream convolving, but just can read files.
This is in its early stages, but should be already pretty usable. To see
what is going on, it
includes a little webserver that gives a status page of what files are
currently being accessed.
(from the README:)
This fuse filesystem takes an original path to a directory with flac-files
and provides these files at the mount point. Accessing audio files will
automatically convolve these on-the-fly using the zita convolver by
Fons Adriaensen. You can directly use filter configuration files that you
have
for jconvolver/fconvolver.
https://github.com/hzeller/folve
So if this is something you're interested in, check it out, provide
feedback patches :)
-henner
16 Sep
16 Sep
6:10 p.m.
New subject: [Ann] Folve: Fuse file system that convolves flac files on-the-fly
On Sun, Sep 16, 2012 at 12:46:42AM -0700, Henner Zeller wrote:
Over the week or so, I've build some fuse
filesystem filters flac files
on-the-fly
using the zita convolver. This makes it real easy to play
around with files and filters. In particular with systems that otherwise
don't support stream convolving, but just can read files.
Interesting project...
One thing: when skipping forward (or seeking in general)
there's no need to convolve all data up to that point.
If P is the new position and L is the lenght of the IR,
then just call Convproc->reset(), seek the input file to
P - L (or 0 if P < L), and convolve up to P. You're
computing a FIR filter, so no more history is required.
If the seek involves an output discontinuity for the user,
you could even just call Conproc->reset(), seek to P, and
proceed normally. The result will be as if there was only
silence before P.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
18 Sep
18 Sep
2:06 a.m.
On 17 September 2012 03:02, Dan Muresan <danmbox(a)gmail.com> wrote:
You've GOT to post usage samples for useful stuff
:)
Yes I will. As soon as I have the first set of features implemented I
want to have, I'll add a simple-to-use example (probably providing one
of the simple reverb examples from Fons jconvolver distribution).
Right now it is only useful if you are already familiar with the
jconvolver filter format.
-h
2:04 a.m.
Hi,
On 16 September 2012 09:10, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sun, Sep 16, 2012 at 12:46:42AM -0700, Henner
Zeller wrote:
I know. The only reason for doing what I am doing is entirely because of
the filesystem semantics.
On the filesystem level, I don't 'see' seeks to audio frame positions but
_only_ file positions. Since the input and the output is a compressed flac
file, the relationship cannot be predicted - this is why I have to walk up
to that point to present a consistent view of the file (in particular if
that file is mmap()ed or if users jump around in it, this is important).
(this would be different if input and output was wav where the relationship
is clear; but wav doesn't provide such a rich header format, so that the
user in media server that display tags and images would be bad).
Over the week or so, I've build some fuse
filesystem filters flac files
on-the-fly
using the zita convolver. This makes it real easy to play
around with files and filters. In particular with systems that otherwise
don't support stream convolving, but just can read files.
Interesting project...
One thing: when skipping forward (or seeking in general)
there's no need to convolve all data up to that point.
If P is the new position and L is the lenght of the IR,
then just call Convproc->reset(), seek the input file to
P - L (or 0 if P < L), and convolve up to P. You're
computing a FIR filter, so no more history is required.
If the seek involves an output discontinuity for the
user,
you could even just call Conproc->reset(), seek to P, and
proceed normally. The result will be as if there was only
silence before P.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
2:16 a.m.
On Sep 17, 2012 8:04 PM, "Henner Zeller" <h.zeller(a)acm.org> wrote:
I know. The only reason for doing what I am doing is entirely because of the
filesystem semantics.
Have you considered OggPCM? Perhaps it has a constant enough bitrate while
still providing rich tags. Not sure how well supported it is though...
Hi,
On 16 September 2012 09:10, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
>
> On Sun, Sep 16, 2012 at 12:46:42AM -0700, Henner Zeller wrote:
>
> > Over the week or so, I've build some fuse filesystem filters flac files
> > on-the-fly
> > using the zita convolver. This makes it real easy to play
> > around with files and filters. In particular with systems that
otherwise
don't support stream convolving, but just can read
files.
Interesting project...
One thing: when skipping forward (or seeking in general)
there's no need to convolve all data up to that point.
If P is the new position and L is the lenght of the IR,
then just call Convproc->reset(), seek the input file to
P - L (or 0 if P < L), and convolve up to P. You're
computing a FIR filter, so no more history is required.
On the filesystem level, I don't 'see' seeks to audio frame positions but
_only_ file positions. Since the input and the output is a compressed flac
file, the relationship cannot be predicted - this is why I have to walk up
to that point to present a consistent view of the file (in particular if
that file is mmap()ed or if users jump around in it, this is important).
(this would be different if input and output was wav
where the
relationship is clear; but wav doesn't provide such a rich header
format,
so that the user in media server that display tags and images would be bad).
If the seek involves an output discontinuity for the user,
you could even just call Conproc->reset(), seek to P, and
proceed normally. The result will be as if there was only
silence before P.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
19 Sep
19 Sep
8:49 p.m.
On 17 September 2012 17:16, Paul Giblock <pgiblox(a)gmail.com> wrote:
On Sep 17, 2012 8:04 PM, "Henner Zeller" <h.zeller(a)acm.org> wrote:
Thanks for the tip. I think OggPCM sounds like a good way to represent
the data with predictable seek behavior. Right now, i didn't run into
the problem for flac files with my current usage pattern (=not much
seeking :) ) though, but it might be a good feature in the future. The
beauty if encoding flac -> flac right now is, that I can just provide
the original headers verbatim to the new file, so I don't have to
worry about extracting the header and re-coding it into a different
header format and probably loosing half of the interesting information
on the way (e.g. libsndfile does not support cover-pictures).
(All my audio files are flac anyway).
Where it immediately can be useful: when reading ogg-vorbis files. I
do re-coding ogg-vorbis -> flac right now in Folve, because apparently
libsndfile needs to read the full input before it can generate the
compressed output -- which is not what I want, so I encode as flac to
have the immediate 'streaming' capabilities. In that case using the
same ogg container but having the data in PCM might be the better
choice; Have to check that libsndfile supports the OggPCM combination.
-h
Hi,
On 16 September 2012 09:10, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
Have you considered OggPCM? Perhaps it has a constant enough bitrate while
still providing rich tags. Not sure how well supported it is though...
On Sun, Sep 16, 2012 at 12:46:42AM -0700, Henner Zeller wrote:
I know. The only reason for doing what I am doing is entirely because of
the filesystem semantics.
On the filesystem level, I don't 'see' seeks to audio frame positions but
_only_ file positions. Since the input and the output is a compressed flac
file, the relationship cannot be predicted - this is why I have to walk up
to that point to present a consistent view of the file (in particular if
that file is mmap()ed or if users jump around in it, this is important).
(this would be different if input and output was wav where the
relationship is clear; but wav doesn't provide such a rich header format, so
that the user in media server that display tags and images would be bad).
Over the week or so, I've build some fuse
filesystem filters flac files
on-the-fly
using the zita convolver. This makes it real easy to play
around with files and filters. In particular with systems that
otherwise
don't support stream convolving, but just can read files.
Interesting project...
One thing: when skipping forward (or seeking in general)
there's no need to convolve all data up to that point.
If P is the new position and L is the lenght of the IR,
then just call Convproc->reset(), seek the input file to
P - L (or 0 if P < L), and convolve up to P. You're
computing a FIR filter, so no more history is required.
If the seek involves an output discontinuity for the user,
you could even just call Conproc->reset(), seek to P, and
proceed normally. The result will be as if there was only
silence before P.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
23 Sep
23 Sep
7:17 p.m.
Hi,
The latest version now contains a simple highpass- and lowpass-filter
to test out the configuration. And a description how to get the Santa
Lucia Basilica reverb example from the jconvolver demo distribution.
Also several new features such as switchable filter configurations at
runtime via the HTTP status server or gapless support.
https://github.com/hzeller/folve#readme
cheers,
-Henner
On 16 September 2012 00:46, Henner Zeller <h.zeller(a)acm.org> wrote:
Hi,
Over the week or so, I've build some fuse filesystem filters flac files
on-the-fly
using the zita convolver. This makes it real easy to play
around with files and filters. In particular with systems that otherwise
don't support stream convolving, but just can read files.
This is in its early stages, but should be already pretty usable. To see
what is going on, it
includes a little webserver that gives a status page of what files are
currently being accessed.
(from the README:)
This fuse filesystem takes an original path to a directory with flac-files
and provides these files at the mount point. Accessing audio files will
automatically convolve these on-the-fly using the zita convolver by
Fons Adriaensen. You can directly use filter configuration files that you
have
for jconvolver/fconvolver.
https://github.com/hzeller/folve
So if this is something you're interested in, check it out, provide
feedback patches :)
-henner
9:40 p.m.
New subject: [Ann] Folve: Fuse file system that convolves flac files on-the-fly
On Sun, Sep 23, 2012 at 10:17:10AM -0700, Henner Zeller wrote:
The latest version now contains a simple highpass- and
lowpass-filter
to test out the configuration. And a description how to get the Santa
Lucia Basilica reverb example from the jconvolver demo distribution.
Be careful when using the Santa Lucia IR. It's the recording of a
gunshot, so the direct sound is a) clipped and b) low-fi. The file
that comes with jconvolver cuts of the direct (dry) sound for that
reason, assuming the normal signal path through a mixer will add it.
In this case it has to be added to the IR. You need something like
# in out gain delay offset length chan file
#------------------------------------------------------------------------
/impulse/read 1 1 0.1 1400 1400 0 1 santalucia.wav
/impulse/read 2 2 0.1 1400 1400 0 2 santalucia.wav
/impulse/dirac 1 1 1 0
/impulse/dirac 2 2 1 0
The ratio of the 'gain' parameters determines the wet/dry ratio.
You can use this at either 44.1 or 48 kHz, the only difference
will be a slightly different (10%) reverb time.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
10:48 p.m.
Hi,
On 23 September 2012 12:40, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sun, Sep 23, 2012 at 10:17:10AM -0700, Henner
Zeller wrote:
Thanks Fons, this is a good idea. Just the santalucia.wav is not very
high quality indeed (and needs heavy attenuation).
But if I understand the filter configuration right, I can't really
just use a gain of 1.0 with the dirac: I need to attenuate the
original signal so that there is enough 'room' for the SantaLucia
reverb to be added ... otherwise the output signal is clipped if
already close to 0dB.
So this is what I did now, essentially adding the original signal to
it with -8dB, the rest 'filled out' with the SantaLucia:
https://github.com/hzeller/folve/blob/master/demo-filters/SantaLucia/filter…
(Change from before:
https://github.com/hzeller/folve/commit/d629c8899d39b96650708fc6b46e5369681…
)
ciao,
-henner
The latest version now contains a simple
highpass- and lowpass-filter
to test out the configuration. And a description how to get the Santa
Lucia Basilica reverb example from the jconvolver demo distribution.
Be careful when using the Santa Lucia IR. It's the recording of a
gunshot, so the direct sound is a) clipped and b) low-fi. The file
that comes with jconvolver cuts of the direct (dry) sound for that
reason, assuming the normal signal path through a mixer will add it.
In this case it has to be added to the IR. You need something like
# in out gain delay offset length chan file
#------------------------------------------------------------------------
/impulse/read 1 1 0.1 1400 1400 0 1 santalucia.wav
/impulse/read 2 2 0.1 1400 1400 0 2 santalucia.wav
/impulse/dirac 1 1 1 0
/impulse/dirac 2 2 1 0
The ratio of the 'gain' parameters determines the wet/dry ratio.
You can use this at either 44.1 or 48 kHz, the only difference
will be a slightly different (10%) reverb time.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
11:12 p.m.
New subject: [Ann] Folve: Fuse file system that convolves flac files on-the-fly
On Sun, Sep 23, 2012 at 01:48:44PM -0700, Henner Zeller wrote:
So this is what I did now, essentially adding the
original signal to
it with -8dB, the rest 'filled out' with the SantaLucia:
https://github.com/hzeller/folve/blob/master/demo-filters/SantaLucia/filter…
Looks very OK !
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
4396
days inactive
4403
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Dan Muresan -
Fons Adriaensen -
Henner Zeller -
Paul Giblock