Ha, so I was really on to something ;)
Is the bug in the meter or in the envelope?
Would you have a workaround for me to get on with the lufs analyser?
Thanks, Klaus
On 08.07.21 19:19, Julius Smith wrote:
> Hi Dario,
>
> The problem seems to be architecture-dependent. I am on a Mac (latest
> non-beta software) using faust2caqt. What are you using?
>
> I do not see the "strange behavior" you describe.
>
> Your test looks good for me in faust2octave, with gain set to 0.01 (-40
> dB, which triggers the display bug on my system). In
> Octave, faustout(end,:) shows
>
> -44.744 -44.968 -44.708
>
> which at first glance seems close enough for noise input and slightly
> different averaging windows. Changing the signal to a constant 0.01, I get
>
> -39.994 -40.225 -40.000
>
> which is not too bad, but which should probably be sharpened up. The
> third value (zi_lp) is right on, of course.
>
> gain = 0.01; // hslider("Gain [unit:dB]",-70,-70,0,0.1) : ba.db2linear;
> sig = gain; //sig = no.noise * gain;
>
> On Thu, Jul 8, 2021 at 3:53 AM Dario Sanfilippo
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi, Julius.
>
> I must be missing something, but I couldn't see the behaviour that
> you described, that is, the gating behaviour happening only for the
> display and not for the output.
>
> If a removethe hbargraphaltogether, I can still see the strange
> behaviour. Just so we're all on the same page, the strange behaviour
> we're referring to is the fact that, after going back to low input
> gains, the displayed levels are -inf instead of some low,
> quantifiable ones, right?
>
> Using a leaky integrator makes the calculations rather inaccurate.
> I'd say that, if one needs to use single-precision, averaging with a
> one-pole lowpass would be best:
>
> import("stdfaust.lib");
> zi = an.ms_envelope_rect(Tg);
> slidingSum(n) = fi.pole(.999999) <: _, _@int(max(0,n)) :> -;
> slidingMean(n) = slidingSum(n)/rint(n);
> zi_leaky(x) = slidingMean(Tg*ma.SR, x * x);
> lp1p(cf, x) = fi.pole(b, x * (1 - b))
> with {
> b = exp(-2 * ma.PI * cf / ma.SR);
> };
> zi_lp(x) = lp1p(1 / Tg, x * x);
> Tg = 0.4;
> sig = no.noise * gain;
> gain = hslider("Gain [unit:dB]",-70,-70,0,0.1) : ba.db2linear;
> level = ba.linear2db : *(0.5);
> process = sig <: level(zi) , level(zi_leaky) , level(zi_lp);
>
> Ciao,
> Dr Dario Sanfilippo
> http://dariosanfilippo.com <http://dariosanfilippo.com>
>
>
> On Thu, 8 Jul 2021 at 00:39, Julius Smith <[email protected]
> <mailto:[email protected]>> wrote:
>
> > I think that the problem is in an.ms_envelope_rect,
> particularly the fact that it has a non-leaky integrator. I
> assume that when large values recirculate in the integrator, the
> smaller ones, after pushing the gain down, are truncated to 0
> due to single-precision. As a matter of fact, compiling the code
> in double precision looks fine here.
>
> I just took a look and see that it's essentially based on + ~ _
> : (_ - @(rectWindowLenthSamples))
> This will indeed suffer from a growing roundoff error variance
> over time (typically linear growth).
> However, I do not see any noticeable effects of this in my
> testing thus far.
> To address this properly, we should be using TIIR filtering
> principles ("Truncated IIR"), in which two such units pingpong
> and alternately reset.
> Alternatively, a small exponential decay can be added: + ~
> *(0.999999) ... etc.
>
> - Julius
>
> On Wed, Jul 7, 2021 at 12:32 PM Dario Sanfilippo
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> I think that the problem is in an.ms_envelope_rect,
> particularly the fact that it has a non-leaky integrator. I
> assume that when large values recirculate in the integrator,
> the smaller ones, after pushing the gain down, are truncated
> to 0 due to single-precision. As a matter of fact, compiling
> the code in double precision looks fine here.
>
> Ciao,
> Dr Dario Sanfilippo
> http://dariosanfilippo.com <http://dariosanfilippo.com>
>
>
> On Wed, 7 Jul 2021 at 19:25, Stéphane Letz <[email protected]
> <mailto:[email protected]>> wrote:
>
> « hargraph seems to have some kind of a gate in it that
> kicks in around -35 dB. » humm…. hargraph/vbargrah only
> keep the last value of their written FAUSTFLOAT* zone,
> so once per block, without any processing of course…
>
> Have you looked at the produce C++ code?
>
> Stéphane
>
> > Le 7 juil. 2021 à 18:31, Julius Smith
> <[email protected] <mailto:[email protected]>>
> a écrit :
> >
> > That is strange - hbargraph seems to have some kind of
> a gate in it that kicks in around -35 dB.
> >
> > In this modified version, you can hear that the sound
> is ok:
> >
> > import("stdfaust.lib");
> > Tg = 0.4;
> > zi = an.ms_envelope_rect(Tg);
> > gain = hslider("Gain [unit:dB]",-10,-70,0,0.1) :
> ba.db2linear;
> > sig = no.noise * gain;
> > process = attach(sig, (sig : zi : ba.linear2db :
> *(0.5) : hbargraph("test",-70,0)));
> >
> > On Wed, Jul 7, 2021 at 12:59 AM Klaus Scheuermann
> <[email protected] <mailto:[email protected]>> wrote:
> > Hi all,
> > I did some testing and
> >
> > an.ms_envelope_rect()
> >
> > seems to show some strange behaviour (at least to me).
> Here is a video
> > of the test:
> > https://cloud.4ohm.de/s/64caEPBqxXeRMt5
> <https://cloud.4ohm.de/s/64caEPBqxXeRMt5>
> >
> > The audio is white noise and the testing code is:
> >
> > import("stdfaust.lib");
> > Tg = 0.4;
> > zi = an.ms_envelope_rect(Tg);
> > process = _ : zi : ba.linear2db : hbargraph("test",-95,0);
> >
> > Could you please verify?
> >
> > Thanks, Klaus
> >
> >
> >
> > On 05.07.21 20:16, Julius Smith wrote:
> > > Hmmm, '!' means "block the signal", but attach
> should save the bargraph
> > > from being optimized away as a result. Maybe I
> misremembered the
> > > argument order to attach? While it's very simple in
> concept, it can be
> > > confusing in practice.
> > >
> > > I chose not to have a gate at all, but you can grab
> one from
> > > misceffects.lib if you like. Low volume should not
> give -infinity,
> > > that's a bug, but zero should, and zero should
> become MIN as I mentioned
> > > so -infinity should never happen.
> > >
> > > Cheers,
> > > Julius
> > >
> > >
> > > On Mon, Jul 5, 2021 at 10:39 AM Klaus Scheuermann
> <[email protected] <mailto:[email protected]>
> > > <mailto:[email protected] <mailto:[email protected]>>>
> wrote:
> > >
> > > Cheers Julius,
> > >
> > >
> > >
> > > At least I understood the 'attach' primitive now
> ;) Thanks.
> > >
> > >
> > >
> > > This does not show any meter here...
> > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> vbargraph("LUFS",-90,0)))
> > > : _,_,!;
> > >
> > > But this does for some reason (although the
> output is 3-channel then):
> > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> vbargraph("LUFS",-90,0)))
> > > : _,_,_;
> > >
> > > What does the '!' do?
> > >
> > >
> > >
> > > I still don't quite get the gating topic. In my
> understanding, the meter
> > > should hold the current value if the input
> signal drops below a
> > > threshold. In your version, the meter drops to
> -infinity when very low
> > > volume content is played.
> > >
> > > Which part of your code does the gating?
> > >
> > > Many thanks,
> > > Klaus
> > >
> > >
> > >
> > > On 05.07.21 18:06, Julius Smith wrote:
> > > > Hi Klaus,
> > > >
> > > > Yes, I agree the filters are close enough. I
> bet that the shelf is
> > > > exactly correct if we determined the exact
> transition frequency, and
> > > > that the Butterworth highpass is close enough
> to the
> > > Bessel-or-whatever
> > > > that is inexplicably not specified as a filter
> type, leaving it
> > > > sample-rate dependent. I would bet large odds
> that the differences
> > > > cannot be reliably detected in listening tests.
> > > >
> > > > Yes, I just looked again, and there are
> "gating blocks" defined,
> > > each Tg
> > > > = 0.4 sec long, so that only ungated blocks
> are averaged to form a
> > > > longer term level-estimate. What I wrote
> gives a "sliding gating
> > > > block", which can be lowpass filtered further,
> and/or gated, etc.
> > > > Instead of a gate, I would simply replace 0 by
> ma.EPSILON so that the
> > > > log always works (good for avoiding denormals
> as well).
> > > >
> > > > I believe stereo is supposed to be handled
> like this:
> > > >
> > > > Lk2 = _,0,_,0,0 : Lk5;
> > > > process(x,y) = Lk2(x,y);
> > > >
> > > > or
> > > >
> > > > Lk2 = Lk(0),Lk(2) :> 10 * log10 : -(0.691);
> > > >
> > > > but since the center channel is processed
> identically to left
> > > and right,
> > > > your solution also works.
> > > >
> > > > Bypassing is normal Faust, e.g.,
> > > >
> > > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> > > vbargraph("LUFS",-90,0)))
> > > > : _,_,!;
> > > >
> > > > Cheers,
> > > > Julius
> > > >
> > > >
> > > > On Mon, Jul 5, 2021 at 1:56 AM Klaus
> Scheuermann <[email protected] <mailto:[email protected]>
> > > <mailto:[email protected] <mailto:[email protected]>>
> > > > <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>> wrote:
> > > >
> > > >
> > > > > I can never resist these things! Faust
> makes it too
> > > enjoyable :-)
> > > >
> > > > Glad you can't ;)
> > > >
> > > > I understood you approximate the filters
> with standard faust
> > > filters.
> > > > That is probably close enough for me :)
> > > >
> > > > I also get the part with the sliding
> window envelope. If I
> > > wanted to
> > > > make the meter follow slowlier, I would
> just widen the window
> > > with Tg.
> > > >
> > > > The 'gating' part I don't understand for
> lack of mathematical
> > > knowledge,
> > > > but I suppose it is meant differently.
> When the input signal
> > > falls below
> > > > the gate threshold, the meter should stay
> at the current
> > > value, not drop
> > > > to -infinity, right? This is so 'silent'
> parts are not taken into
> > > > account.
> > > >
> > > > If I wanted to make a stereo version it
> would be something like
> > > > this, right?
> > > >
> > > > Lk2 = par(i,2, Lk(i)) :> 10 * log10 :
> -(0.691);
> > > > process = _,_ : Lk2 : vbargraph("LUFS",-90,0);
> > > >
> > > > Probably very easy, but how do I attach
> this to a stereo
> > > signal (passing
> > > > through the stereo signal)?
> > > >
> > > > Thanks again!
> > > > Klaus
> > > >
> > > >
> > > >
> > > > >
> > > > > I made a pass, but there is a small
> scaling error. I think
> > > it can be
> > > > > fixed by reducing boostFreqHz until the
> sine_test is nailed.
> > > > > The highpass is close (and not a source
> of the scale error),
> > > but I'm
> > > > > using Butterworth instead of whatever
> they used.
> > > > > I glossed over the discussion of
> "gating" in the spec, and
> > > may have
> > > > > missed something important there, but
> > > > > I simply tried to make a sliding
> rectangular window, instead
> > > of 75%
> > > > > overlap, etc.
> > > > >
> > > > > If useful, let me know and I'll propose
> it for analyzers.lib!
> > > > >
> > > > > Cheers,
> > > > > Julius
> > > > >
> > > > > import("stdfaust.lib");
> > > > >
> > > > > // Highpass:
> > > > > // At 48 kHz, this is the right highpass
> filter (maybe a
> > > Bessel or
> > > > > Thiran filter?):
> > > > > A48kHz = ( /* 1.0, */ -1.99004745483398,
> 0.99007225036621);
> > > > > B48kHz = (1.0, -2.0, 1.0);
> > > > > highpass48kHz = fi.iir(B48kHz,A48kHz);
> > > > > highpass = fi.highpass(2, 40); //
> Butterworth highpass:
> > > roll-off is a
> > > > > little too sharp
> > > > >
> > > > > // High Shelf:
> > > > > boostDB = 4;
> > > > > boostFreqHz = 1430; // a little too high
> - they should give
> > > us this!
> > > > > highshelf = fi.high_shelf(boostDB,
> boostFreqHz); // Looks
> > > very close,
> > > > > but 1 kHz gain has to be nailed
> > > > >
> > > > > kfilter = highshelf : highpass;
> > > > >
> > > > > // Power sum:
> > > > > Tg = 0.4; // spec calls for 75% overlap
> of successive
> > > rectangular
> > > > > windows - we're overlapping MUCH more
> (sliding window)
> > > > > zi = an.ms_envelope_rect(Tg); // mean
> square: average power =
> > > > energy/Tg
> > > > > = integral of squared signal / Tg
> > > > >
> > > > > // Gain vector Gv = (GL,GR,GC,GLs,GRs):
> > > > > N = 5;
> > > > > Gv = (1, 1, 1, 1.41, 1.41); // left
> GL(-30deg), right GR
> > > (30), center
> > > > > GC(0), left surround GLs(-110), right
> surr. GRs(110)
> > > > > G(i) = *(ba.take(i+1,Gv));
> > > > > Lk(i) = kfilter : zi : G(i); // one
> channel, before summing
> > > and before
> > > > > taking dB and offsetting
> > > > > LkDB(i) = Lk(i) : 10 * log10 : -(0.691);
> // Use this for a mono
> > > > input signal
> > > > >
> > > > > // Five-channel surround input:
> > > > > Lk5 = par(i,5,Lk(i)) :> 10 * log10 :
> -(0.691);
> > > > >
> > > > > // sine_test = os.oscrs(1000); // should
> give –3.01 LKFS, with
> > > > > GL=GR=GC=1 (0dB) and GLs=GRs=1.41 (~1.5 dB)
> > > > > sine_test = os.osc(1000);
> > > > >
> > > > > process = sine_test : LkDB(0); // should
> read -3.01 LKFS -
> > > high-shelf
> > > > > gain at 1 kHz is critical
> > > > > // process = 0,sine_test,0,0,0 : Lk5; //
> should read -3.01
> > > LKFS for
> > > > > left, center, and right
> > > > > // Highpass test: process = 1-1' <:
> highpass, highpass48kHz;
> > > // fft in
> > > > > Octave
> > > > > // High shelf test: process = 1-1' :
> highshelf; // fft in Octave
> > > > >
> > > > > On Sat, Jul 3, 2021 at 1:08 AM Klaus
> Scheuermann
> > > <[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > > > <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>
> > > > > <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>
> > > <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>>> wrote:
> > > > >
> > > > > Hello everyone :)
> > > > >
> > > > > Would someone be up for helping me
> implement an LUFS
> > > loudness
> > > > analyser
> > > > > in faust?
> > > > >
> > > > > Or has someone done it already?
> > > > >
> > > > > LUFS (aka LKFS) is becoming more and
> more the standard for
> > > > loudness
> > > > > measurement in the audio industry.
> Youtube, Spotify and
> > > broadcast
> > > > > stations use the concept to
> normalize loudness. A very
> > > > positive side
> > > > > effect is, that loudness-wars are
> basically over.
> > > > >
> > > > > I looked into it, but my programming
> skills clearly
> > > don't match
> > > > > the level for implementing this.
> > > > >
> > > > > Here is some resource about the topic:
> > > > >
> > > > > https://en.wikipedia.org/wiki/LKFS
> <https://en.wikipedia.org/wiki/LKFS>
> > > <https://en.wikipedia.org/wiki/LKFS
> <https://en.wikipedia.org/wiki/LKFS>>
> > > > <https://en.wikipedia.org/wiki/LKFS
> <https://en.wikipedia.org/wiki/LKFS>
> > > <https://en.wikipedia.org/wiki/LKFS
> <https://en.wikipedia.org/wiki/LKFS>>>
> > > > <https://en.wikipedia.org/wiki/LKFS
> <https://en.wikipedia.org/wiki/LKFS>
> > > <https://en.wikipedia.org/wiki/LKFS
> <https://en.wikipedia.org/wiki/LKFS>>
> > > > <https://en.wikipedia.org/wiki/LKFS
> <https://en.wikipedia.org/wiki/LKFS>
> > > <https://en.wikipedia.org/wiki/LKFS
> <https://en.wikipedia.org/wiki/LKFS>>>>
> > > > >
> > > > > Specifications (in Annex 1):
> > > > >
> > > >
> > >
>
> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf>
> > >
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf>>
> > > >
> > >
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf>
> > >
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf>>>
> > > > >
> > > >
> > >
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf>
> > >
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf>>
> > > >
> > >
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf>
> > >
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>
> <https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf>>>>
> > > > >
> > > > > An implementation by 'klangfreund'
> in JUCE / C:
> > > > >
> https://github.com/klangfreund/LUFSMeter
> <https://github.com/klangfreund/LUFSMeter>
> > > <https://github.com/klangfreund/LUFSMeter
> <https://github.com/klangfreund/LUFSMeter>>
> > > > <https://github.com/klangfreund/LUFSMeter
> <https://github.com/klangfreund/LUFSMeter>
> > > <https://github.com/klangfreund/LUFSMeter
> <https://github.com/klangfreund/LUFSMeter>>>
> > > > >
> <https://github.com/klangfreund/LUFSMeter
> <https://github.com/klangfreund/LUFSMeter>
> > > <https://github.com/klangfreund/LUFSMeter
> <https://github.com/klangfreund/LUFSMeter>>
> > > > <https://github.com/klangfreund/LUFSMeter
> <https://github.com/klangfreund/LUFSMeter>
> > > <https://github.com/klangfreund/LUFSMeter
> <https://github.com/klangfreund/LUFSMeter>>>>
> > > > >
> > > > > There is also a free LUFS Meter in
> JS / Reaper by
> > > Geraint Luff.
> > > > > (The code can be seen in reaper, but
> I don't know if I
> > > should
> > > > paste it
> > > > > here.)
> > > > >
> > > > > Please let me know if you are up for it!
> > > > >
> > > > > Take care,
> > > > > Klaus
> > > > >
> > > > >
> > > > >
> _______________________________________________
> > > > > Faudiostream-users mailing list
> > > > >
> [email protected]
> <mailto:[email protected]>
> > > <mailto:[email protected]
> <mailto:[email protected]>>
> > > >
> <mailto:[email protected]
> <mailto:[email protected]>
> > > <mailto:[email protected]
> <mailto:[email protected]>>>
> > > > >
> <mailto:[email protected]
> <mailto:[email protected]>
> > > <mailto:[email protected]
> <mailto:[email protected]>>
> > > >
> <mailto:[email protected]
> <mailto:[email protected]>
> > > <mailto:[email protected]
> <mailto:[email protected]>>>>
> > > > >
> > > >
> > >
>
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
> > >
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>>
> > > >
> > >
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
> > >
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>>>
> > > > >
> > > >
> > >
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
> > >
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>>
> > > >
> > >
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
> > >
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>>>>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > "Anybody who knows all about nothing
> knows everything" --
> > > Leonard
> > > > Susskind
> > > >
> > > >
> > > >
> > > > --
> > > > "Anybody who knows all about nothing knows
> everything" -- Leonard
> > > Susskind
> > >
> > >
> > >
> > > --
> > > "Anybody who knows all about nothing knows
> everything" -- Leonard Susskind
> >
> >
> > --
> > "Anybody who knows all about nothing knows everything"
> -- Leonard Susskind
> > _______________________________________________
> > Faudiostream-users mailing list
> > [email protected]
> <mailto:[email protected]>
> >
>
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
>
>
>
> _______________________________________________
> Faudiostream-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
>
>
>
> --
> "Anybody who knows all about nothing knows everything" --
> Leonard Susskind
>
>
>
> --
> "Anybody who knows all about nothing knows everything" -- Leonard Susskind
>
>
> _______________________________________________
> Faudiostream-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
_______________________________________________
Faudiostream-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
