Hey guys!
This is an Offtopic question, really, but I wanted to ask people I know and
people who are developers - what are the reasons there are (almost) no
viruses on Linux?
The typical argument is that there are not too much users.
I generally do not agree with this argument and point to architectural
reasons, number of distros, community reasons and the openness of the
platform. Additionally, I even argue that the more users, the faster news
about a potential risk spreads.
However, several of my friends and colleagues at work who are long time
Linux users have argued that in the end it is still the number of users,
since no architecture is perfect and virus writers will find a way to
penetrate the system and target all known distros.
I am wondering if I am missing something. Does anyone on this list thinks
that number of users does play more than a minor role?
--
Louigi Verona
http://www.louigiverona.ru/
Hello,
I have been coding the porting of the AMS internal modules to LV2
plugins using the Lv2-C++-Tools.
The more I'm progressing, the more I am wondering if there are any
limitations involved in using this library, especially these days
where a lot of new features are being added to the Lv2 Extensions.
For example, I am coding a plugin that output the position of the
mouse cursor as two control ports (handy to develop a kind of theremin
synth).
Getting the cursor position from the X Library is an expensive
operation, and the new Worker Extension seems perfect for the job, but
I can't figure out if somehow it is compatible or not with the
Lv2-C++-Tools.
The most obvious pros of using Lv2-C++-Tools is its simplicity.
Porting an AMS module takes only 20 to 30 minutes with it, while doing
it without the help of the library takes much more time and is way
more tedious.
(I am much more confortable coding in C++ than C, but the question
deserves to be asked, am I doing something wrong here that I find it
way more difficult to code without the help of Lv2-C++-Tools?)
So I am putting the question to the community: what path you would you
advise to follow? With or Without Lv2-C++-Tools?
Hi all,
I would like to announce the release of aj-snapshot-0.9.6
aj-snapshot is a command line utility to store/restore
ALSA and/or JACK connections to/from an XML file.
The most important change in this release is that aj-snapshot
behaves differently in daemon mode. In the previous version
ALSA connections were restored continually, and JACK connections
whenever the connection graph had changed.
In this version, aj-snapshot will restore connections once when
it is started, and after that when new ports are registered in
ALSA or JACK. You can specify (in milliseconds) how often aj-snapshot
will poll for newly registered ports (-p --poll ms). The default is 1 second.
This means that you have a lot more freedom to change the connections
while the daemon is running, and gives you the opportunity to save
(and maybe reload) a new connection state.
Other changes include:
- added manual file
- rewrite of aj-snapshot.c to make it more readable and maintainable,
and to have less code repetition.
As always, there will be bugs, and I would be very
grateful if you would report them on the sourceforge site.
direct download:
http://sourceforge.net/projects/aj-snapshot/files/aj-snapshot-0.9.5.tar.bz2…
aj-snapshot website:
http://aj-snapshot.sourceforge.net/
bug tracker:
http://sourceforge.net/tracker/?group_id=311291&atid=1310488
feature requests:
http://sourceforge.net/tracker/?group_id=311291&atid=1310491
to clone the git repository:
git clone git://gitorious.org/aj-snapshot/aj-snapshot.git
Hope you enjoy,
lievenmoors
Guitarix release guitarix2-0.22beta1
The next shiny new Guitarix version! Guitarix is a tube amplifier
simulation for jack, with effect modules and an additional stereo
effect chain.
Download from http://sourceforge.net/projects/guitarix/
You can find some screenshots and explanations of the new version in
http://sourceforge.net/apps/mediawiki/guitarix/index.php?title=EnhancedUI
Many things changed in the user interface. Now you can move rack units
by drag and drop (reflecting the signal flow), store individual
settings for each rack unit and use preset banks with several settings
for the whole rack. It's easy to take our "factory presets" and make
your own customized bank, or make your own from scratch and share it
on the Guitarix forum.
There is a new "live play mode" with only the info you need on stage
(it's fullscreen, no other penguins around), and a preset picking mode
with a foot switch (midi or usb, or if you don't have one even the
space bar of your keyboard) and the strings of your guitar to switch
settings.
Rack units are now put into categories, and two new ones are a noise
gate for high noise levels and a univibe emulation. Thanks go to the
developer of abGate and Ryan Billing from Rakarrack who helped
porting his univibe code and made the inclusion of it possible.
This is already too long, please check it out and give feedback if you
find a problem, this version is still beta.
Please refer to our project page for more information:
http://guitarix.sourceforge.net/
download site:
http://sourceforge.net/projects/guitarix/
please report bugs and suggestions in our forum:
http://sourceforge.net/apps/phpbb/guitarix/
here you can find a couple of examples produced by guitarix users:
http://sourceforge.net/apps/phpbb/guitarix/viewtopic.php?f=11&t=83
have fun
_________________________________________________________________________
For extra Impulse Responses, guitarix uses the zita-convolver library,
and, for resampling we use zita-resampler, both written by Fons
Adriaensen.
http://kokkinizita.linuxaudio.org/linuxaudio/index.html
We use the marvellous faust compiler to build the amp and most effects
and will say thanks to
: Julius Smith
http://ccrma.stanford.edu/realsimple/faust/
: Albert Graef
http://q-lang.sourceforge.net/examples.html#Faust
: Yann Orlary
http://faust.grame.fr/
________________________________________________________________________
guitarix development team
Updates available now at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads>
zita-alsa-pcmi-0.2.0
* Now includes some dirty hacks (implemented via the debug
options parameter so they don't clutter the API) to support
the -L option of
zita-ajbridge-0.2.2
* Fixed the bug that made it fail with Jack period sizes
>= 1024 (filter coefficients going out of range).
* Added some hacks, activiated by the -L option, to make
it work with ALSA's loop devices.
The latter requires some clarification.
The two apps provided by zita-ajbridge were never intented to be
used with the ALSA loop devices. They were developed to provide
additional and full quality capture or playback channels to Jack,
using a real soundcard.
Yet most people trying the first release used them with the
loop devices, to provide a Jack interface to some misbehaving
apps such as flash player or skype. Using the loop device is
required since those apps refuse to work with ALSA's Jack
plugin. It's a dirty hack using an unwanted resampling step,
but it seems there is no working alternative.
The ALSA loop devices presents themselves as hw: devices, but
they don't behave like a real one:
* Timing of period wakeups is quantised to a much too high
value, and produces lots of jitter, worse than even the
most crappy USB interface. It also makes using the device
with small period sizes impossible, as wakeups occur when
it's almost too late. The next cycle will xrun in that case.
* The loop devices have 32 channels. They allow to be opened
with a different channel count at both ends, but then make
a mess of it. For example mplayer's two channels will be
spread out over the available 32, making it run at 16 times
normal speed.
To run zita-a2j or zita-j2a with the ALSA loop device:
* Use the -L option. This forces two things: the sample format
will be 16-bit, and the device is opened in 2-channel mode.
This makes it usable to apps at the other end which can't deal
with floats or more than 2 channels.
Note that just using -c 2 (which is also the default) still
opens the ALSA device with all its channels, as must be done
on a real hw: device, so that won't work.
* Use at least -p 256 -n 3, or -p 512 or higher (on the ALSA
device - Jack's parameters don't matter).
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)
Hello,
Does anyone know what sort of timer is used by the ALSA
loop device, and if this can be changed in some way ?
On the system I'm working on now, wakeup times while waiting
for a period to be available (as done by Jack and zita-alsa-pcmi)
seem to be quantised in steps of 3.3ms or so. Which means it
sometimes wakes up 3/4 or more of a period too late. Next one
will be xrun in that case.
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)
Hello all,
The first official release of zita-ajbridge is now available at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads>.
Quoting the README:
This package provides two applications, zita-a2j and zita-j2a.
They allow to use an ALSA device as a Jack client, to provide
additional capture (a2j) or playback (j2a) channels.
Functionally these are equivalent to the alsa_in and alsa_out
clients that come with Jack, but they provide much better audio
quality. The resampling ratio will typically be stable within
1 PPM and change only very smoothly. Delay will be stable as
well even under worse case conditions, e.g. the Jack client
running near the end of the cycle.
You will also need the latest zita-resampler and zita-alsa-pcmi
libraries.
All feedback welcome.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
On Mon, Mar 19, 2012 at 06:58:29PM +0100, Robin Gareus wrote:
> # mplayer -ao alsa,device=hw=1,0 some_music.wav
> # zita-a2j -dhw:1,1
>
> I get endless messages:
> Starting synchronisation.
> Detected excessive timing errors, waiting 15 seconds.
> This may happen with current Jack1 after freewheeling.
(meanwhile I'm back home, the loopback device is hw:3 here)
[terminal 1]
fons@zita1:/audio/audiofiles/tracks> mplayer -ao alsa:device=hw=3.1 diana-krall-almost-blue-44.wav
MPlayer SVN-r34426-4.6.2 (C) 2000-2011 MPlayer Team
181 audio & 384 video codecs
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing diana-krall-almost-blue-44.wav.
Audio only file format detected.
Load subtitles in ./
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 4.0 (04.0) of 244.0 (04:04.0) 0.1%
...
[terminal 2]
fons@zita1:~> zita-a2j -d hw:3,0 -r 44100
Starting synchronisation
/me makes connections in qjackctl and hears lovely piano intro...
So this just works. I do indeed have to start mplayer first, but
only the first time. After that I can stop and restart mplayer
without problem. This is probably some quirk of the loopback
device. There is no such thing as 'requesting exclusive access'
in the ALSA pcm API - it depends only on the device.
> The message is repeated every ~15 sec; and it does not stop.
> Each time a message is printed there's a short very jittery sound (I can
> discern the music) but it remains silent for the remaining time.
The silence is intentional - the app waits for the dust to
settle down after it has detected 'impossible' timing info
from either Jack's DLL or from the one tracking the ALSA device.
There was a bug in the loopback device - it returned the wrong
type of event when using poll() in some cases. It's fixed in
1.0.24. That would certainly explain what you see.
> How do you conduct this test?
>
> I assume that there is no other ALSA-client involved and you use the
> loopback in float/32 mode, w/native samplerate.
Zita-a2j and j2a use libzita-alsa-pmci to access ALSA devices.
It uses exactly the same methods as Jack's backend - very early
versions (libclalsadrv 7 years ago) were in fact a C++ copy
of Jack's backend. That means that whatever works with Jack
will work with zita-a2j and j2a or any of my apps using ALSA.
AFAIK Jack doens't run well with dmix/dsnoop either. And anyway
there's no reason to use them with Jack.
To run the delay test (assuming hw:3 is the loopback device):
[Terminal 1]
zita-a2j -d hw:3,0
[Terminal 2]
zita-j2a -d hw:3,1
[Terminal 3]
jack_delay
and make the required connections.
The off-list reply was a typo - back on LAD now.
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)
