Hi phil,
i used different distros... at the moment im using linux mint 12 with rt
patch, ubuntu studio 9.04 to 10.04 with lowlatency kernel. on any system
the 9652 was running fine.
if you just want to record stuff you dont need rt.
only if you want to do processing of any kind, rt is needed.
the 9632 has no expansion board, therefore it only has 16 in and 16out.
the 9652 is the same card but with the expansion board, capable of 24
in/out.
bye
Ck
On 28.03.2012 14:59, Phil T wrote:
>
> Hi Christoph,
>
>
> Thank you ! I am really new to hardware and stuff. I am just
> wondering what linux distro are you using ? Do you think ubuntu may
> suffice ? I have read some threads suggesting to manually compile a
> kernel enabling rt and Im just wondering if you have manually compiled
> a kernel in your case ? Lastly, in the RME homepage, it says that the
> HDSP 9652 can have up to 16 inputs. However if I am not mistaken, it
> also says it has 3 ADAT input so Im just wondering with 3 ADAT input,
> it could be possibly take in 24 inputs all in all. Thank you very much.
>
> Phil
>
>
>
>
>
>
>
> On Wed, Mar 28, 2012 at 6:35 PM, Christoph Kuhr <christoph.kuhr(a)web.de
> <mailto:christoph.kuhr@web.de>> wrote:
>
> Hi,
>
> im running it for a few year... works perfect
>
> bye
> Ck
>
> On 28.03.2012 01:44, Phil T wrote:
>> Hi Everyone
>>
>> Im would like to experiment using microphone arrays ( 24 channels
>> ) and I am just wondering if it is possible for me to use 3 units
>> of Behringer ADA8000 connected via ADAT to HDSP 9652. My tools
>> run only with ALSA supported devices and I checked through ALSA
>> website, the HDSP 9652 seemed to be OK. Im just wondering if the
>> set-up I mentioned is possible ? Will there be any issue at all
>> if i use the ADA8000 as far as ALSA is concerned ? Thank you very
>> much, I really would appreciate any suggestions or comments.
>> Thank you
>>
>>
>> Phil
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev(a)lists.linuxaudio.org <mailto:Linux-audio-dev@lists.linuxaudio.org>
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> <mailto:Linux-audio-dev@lists.linuxaudio.org>
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
Hi all,
Pretty strong consensus is that the LV2 specs being a bunch of packages
is a nuisance. So, I plan to start releasing them all in one package.
People have asked for this, but I'm not positive it's what they want.
The main odd consequence would be packages checked by configure scripts
(via pkg-config) will not correlate with tarballs. For example, a
program may check for lv2-state-2.4 but no tarball with that name will
actually exist. It will be in lv2-everything-2012-03-21 or whatever.
It would be difficult to correlate which version of lv2-everything
contains a recent enough version of what you need, if something is
failing to configure.
I don't think it's feasible or wise to mash everything in to one package
right down to the pkg-config level, but I'm open to arguments otherwise.
Extensions are independently versioned so changes to them don't affect
the version of others. In all the ways that count, extensions are
completely decentralized and separate (anyone can make one and
distribute it, or not, on their own), but maybe that doesn't mean they
need to be packaged that way?
In short, I am ready and willing to reshape the packaging to make life
easy and to ease adoption as much as possible, but nobody has come up
with exactly what that is. All suggestions welcome, including blatant
"this is all ridiculous crap and you should just <painfully simple
approach here>" kind of thoughts...
Cheers,
-dr
> > "Shared data plus locking" is a pretty crap model in general, really.
> > When people talk about all the complications that threads introduce,
> > they're really talking about this. Shared mutable state is the
> cancer of multi-threaded programming.
This should be tattooed on every newbie. ;)
Visualize your GUI running on a 64-bit iPad in Madrid, and your DSP running
on 32-bit Ubuntu in Seattle. Design your API accordingly.....
Best Regards,
Jeff
> Lignux systems only have write access to their home directories, which
> the system does not run software from by default.
So Malware can trash your personal documents and steal your identity.....but
the kernel is safe?
> Windows isn't a victim of its own popularity, it's a victim of being
> crap.
Yeah, While the average programmer makes 20 errors per 1000 lines-of-code.
Linux programmers, having being on a mission form god, NEVER make such
mistakes, therefore Linux is has no exploitable flaws.
;)
Seriously though, this is *SO* off topic.
Best Regards,
Jeff
> Message: 3
> Date: Fri, 23 Mar 2012 20:15:23 -0400
> From: David Robillard <d(a)drobilla.net>
> Subject: Re: [LAD] Linux Malware
> To: Louigi Verona <louigi.verona(a)gmail.com>
> Cc: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
> Message-ID: <1332548123.6586.15.camel(a)verne.drobilla.net>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, 2012-03-22 at 18:17 +0300, Louigi Verona wrote:
> > 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.
>
> Maybe "typical" in Redmond... the typical sane argument is that users
> on
> Lignux systems only have write access to their home directories, which
> the system does not run software from by default.
>
> Windows, on the other hand, traditionally had users running with
> complete access to the system. Add to the mix notoriously flaky
> low-quality code, slow moving development, and a core system built from
> numerous layers of piled legacy crap, and it'd be shocking if exploits
> *didn't* run rampant.
>
> Anyone claiming that any system would have been as badly affected in
> Windows' situation has no idea what they're talking about. The system
> essentially didn't have any form of security whatsoever. The security
> model wasn't flawed, it *wasn't there*. You didn't have to exploit the
> system to get viruses and malware on it, you just had to get the user
> to
> run something.
>
> Windows isn't a victim of its own popularity, it's a victim of being
> crap.
>
> -dr
>
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
