Hi
As of 2011-01-16 I have skipped the development of jcgui, and still I
wouldn't maintain/develop it any longer.
But it get downloaded and used by some users and I receive requests and
bug-reports for it.
So I decide to fix the most related bugs and upload a new version, to
get rid of that.
* fix file not load when white space in path
* fix resampling (use zita-resampler now)
* fix build with gcc 4.7
* various small fixes
Still, I wouldn't recommend to use jcgui, please use IR_LV2 instead,
but, if you really would use jcgui, please update it.
http://sourceforge.net/projects/jcgui/files/jcgui/jcgui-0.8.tar.bz2/download
regards
hermann
I have explicitly asked about block length restrictions on l-a-d several
times, but of course that doesn't work. Setting up an idea to be flamed
works wonderfully though (mining that most plentiful resource of
assholes on mailing lists). The convoLV2 announcement served this
purpose nicely. In summary:
Convolution is the only reason anyone has come up with for a power of 2
block length restriction. Apparently that is wrong.
Only one argument has ever been posed for a fixed restriction, and that
was wrong too (outside LADSPA anyway, where we are not forced to use
control ports).
So, unless anyone has new compelling examples, we have some new
implementation recommendations for the block length restrictions defined
in LV2 1.2.0:
* Fixed and power of two can be difficult or impossible to implement,
and are not useful, so hosts should not bother trying to implement
either (except where it is trivial), and plugins should not expect
them to.
* The remaining restrictions, minimum and maximum, are needed to do
some things without latency, and are useful for performance reasons,
so hosts should try to implement this if possible. Plugins should
only require these if absolutely necessary, since some hosts may not
be able to implement minimum in particular. convoLV2 is an example
of a plugin with minimum and maximum restrictions.
As before, all hosts should implement passing the maximum length to the
plugin, which is often required and easy to do.
There is one issue related to minimum, buffer alignment, which is useful
for SIMD (e.g. using SSE). This has not yet been addressed in the
specifications.
-dr
>
>
> Message: 13
> Date: Sun, 21 Oct 2012 19:57:31 +0000
> From: Fons Adriaensen <fons(a)linuxaudio.org>
> To: David Robillard <d(a)drobilla.net>
> Cc: linux-audio-dev(a)lists.linuxaudio.org
> Subject: Re: [LAD] ANN: convoLV2 0.2
> Message-ID: <20121021195731.GC6724(a)linuxaudio.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Oct 21, 2012 at 03:49:30PM -0400, David Robillard wrote:
>
>> The appropriate thing to use on OSX is mach semaphores. This code is
>> terrible.
>
> I'd be most happy to replace the current code with
> some using Mach semas. Patches will be much appreciated.
>
>>> (A "blocking in a real-time thread is acceptable" argument)
>
> Yes, in some cases that is acceptable.
>
>>> (Hilarious appeal to irrelevant authority)
>
> Much more relevant than you are.
>
> Ciao,
>
> --
> FA
>
You can use semas on OSX, you'll need to use sem_open API instead of sem_init. Using here: sem_open, sem_post/sem_wait, sem_unlink/sem_close with success (In Faust Work Stealing Scheduler code). And semas are actually a slight wrapper over Mach semas. You can check that in XNU source (here for instance http://opensource.apple.com/release/mac-os-x-1068/)
Stéphane
convoLV2 is an LV2 plugin to convolve audio signals without additional
latency.
https://github.com/x42/convoLV2https://github.com/x42/convoLV2/tarball/v0.2
convoLV2 is in an early stage of development and is not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length restrictions, in this case:
* Maximum block length must be passed as an instantiate option
* Block length must always be a power of 2 (a required feature)
See the links in the README and on the github page for details about
these features. The first should be trivial to implement in any host,
which is highly recommended. The second may be difficult or impossible,
though it is trivial in hosts that run plugins directly on the Jack
cycle[1] or process files with fixed parameters.
This plugin is intended to provide latency-free synchronous convolution,
which inherently requires these restrictions. It does not, and will not
ever, do latent audio buffering in the plugin itself (though a generic
wrapper to do so is a good idea...)
This release is known to work in Jalv 1.2.0. If you're feeling
adventurous and remove the power of 2 feature requirement from the data,
it will also work in Ardour3. Sometimes. Maybe.
convoLV2 is jointly developed by Robin Gareus (who wrote the entire
plugin before LV2 could properly support it) and David Robillard (who
invented/implemented the missing LV2 pieces).
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
This announcement is exclusive to developer mailing lists. Feel free to
reply with any thoughts, and report back with any host implementation
progress so the README can be updated.
Happy Hacking,
-dr
[1] Assuming the Jack block length is a power of 2 anyway, which is not
actually guaranteed, but is true in any case sane enough to care about.
Hello all,
My ex-collegues at Alcatel are screaming for help. They want to run
an app (as root, debatable but that's another story) using SCHED_FIFO
threads on an openSuSE 11.4 system.
Using the 'default' kernel (which has CONFIG_PREEMPT not set), this
works. Using the 'desktop' kernel (CONFIG_PREEMPT=y) they get an
EPERM when trying to start a RT thread, even as root.
As I haven't used SuSE for ages, has anyone an idea of what is
happening here ?
TIA,
--
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)
You (Fons) obviously know your stuff when it comes to implementing
convolution, and I'm very grateful you gave us libzita-convolver, but I
have to disagree with this statement:
On Sat, 2012-10-20 at 12:00 +0000, Fons Adriaensen wrote:
> Thirdly, for the use case of reverbs, the whole latency issue is
> just irrelevant. A reverb IR should not contain the direct sound
> (since this will be mixed in separately), and in fact the first
> 10 ms or so should be silence anyway, they don't contribute to
> the effect and just cause coloration. Which means you can adopt
> a scheme that permits arbitrary block sizes by allowing one (Jack)
> period of latency. Just remove as many samples from the start of
> the IR to compensate.
When you use a reverb plugin for ambience or things like the Bricasty M7
Bass XXL impulse, the coloration it is 90% of the effect you are using
the plugin for.
There is a whole range of useful coloration to be had by changing the
pre-delay within 0-20ms. Often it will sound best with 0ms, because that
how the maker of the impulse listened to it.
An ambience impulse is an important part of practically every mix I do.
That is why I am so happy with libzita-convolver and it's offspring :)
That is also why I would *love* latency compensation on buses in Ardour.
All the best,
Bart.
Hi Harry,
Thanks for your suggestions and sample.
I can understand the sample almost, and will start to learn JACK from now on.
Please give me more guidance if i encounter trouble on JACK.
Thanks in advance!
Best regards
Spring
------------------ 原始邮件 ------------------
发件人: "Harry van Haaren"<harryhaaren(a)gmail.com>;
发送时间: 2012年10月19日(星期五) 下午5:50
收件人: "新月如钩"<46620410(a)qq.com>;
抄送: "linux-audio-dev"<linux-audio-dev(a)lists.linuxaudio.org>;
主题: Re: 回复： [LAD] About some interface of aplay
On , 新月如钩 <46620410(a)qq.com> wrote:
> I want to learn some Linux audio related technologies, and going to start from ALSA.
It is easier to start with JACK.
If you understand the code in this file, then you understand the basics behind writing a JACK audio program.
https://github.com/jackaudio/example-clients/blob/master/simple_client.c
It is much harder to learn to code for ALSA, as there are many steps involved before you can play sound.
Make life easy for yourself and let JACK do that hard work: stand on the shoulders of giants. -Harry
Hi SxDx,
Thanks for your feedback, it seems i download a outdated version.
I think these interface may be have abandoned.
sorry to trouble you! Thanks for your feedback again!
Best regards
Spring
------------------ 原始邮件 ------------------
发件人: "SxDx"<sed(a)free.fr>;
发送时间: 2012年10月19日(星期五) 晚上9:38
收件人: "新月如钩"<46620410(a)qq.com>;
抄送: "linux-audio-dev"<linux-audio-dev(a)lists.linuxaudio.org>;
主题: Re: [LAD] About some interface of aplay
> From: "新月如钩" <46620410(a)qq.com>
> I analyze the source code of aplay and very confused on follow
> interfaces:
> snd_pcm_playback_info()
> snd_pcm_playback_format()
> snd_pcm_playback_params()
>
> The aplay is belongs to alsa-utils that also is a application.
> It should be use interfaces of alsa-lib, but why i can't find
> these interfaces in alsa-lib ?
> Could you tell me where can find out these interface?
what version of alsa-utils do you have?
These functions are not in alsa-utils-1.0.24.2
that I have here nor in the git repository.
