I hope it gets through this time...
On Wed, Sep 28, 2005 at 06:05:55PM +0200, Antonio wrote:
>
> And yes I'm going to try the 2.6.13 too. Do you know if I can use the
> realtime-lsm module with the .13? I don't care about security risk on
> this machine.
>
> Anyhow, many thanks for the useful answer you give me so far ;-).
>
> Best Regards,
>
> ~ Antonio
>
Hello.
I believe you can use the realtime-lsm with recent kernels, but it is
not the recommended approach any more. The new rt-rlimits way doesn't
require to patch the kernel. But as long as the distributions don't do
this for you, you have to install a modified pam. There is information
on this wiki: http://alsa.opensrc.org/RealtimeKernelAndPAM. I also put
some pam packages for Debian unstable there, that might well work testing
as the libpam-modules version is the same for both branches (at the
moment).
Burkhard
> Yes, the FA-101 works but I can't tell you the numbers for latency.
The site has a nice table of working setups, but no user emails. I'd ask
them directly.
> What do you mean with restristrions on buffers (=latency?)?
AFAIK, usb cards impose 48kHz (96), 48/3 buffer setup to please
everybody in the chain.
Jackd needs buffers to be power of 2, and usb-audio - multiples of 1ms.
> we consider the 192 kHz more as marketing gag :)
That's to compete with Fireface.
> Hope that helps.
Thank you.
Dmitry.
tim hall wrote:
> On Friday 30 September 2005 01:30, Shayne O'Connor wrote:
>
>>hmmm ... are you sure you didn't mean to be rude? did you think *i*
>>intended it to be funny?
>
>
> Yes, I'm really sure I didn't intend rudeness. I apologise for the unclarity.
> It was an honest reaction to the piece.
> Keep up the good work.
is cool ... even though i'm open to criticism, i'm ultra-sensitive to
people finding stuff i've done funny ... unless, of course, it is
intended that way :)
anyway, i'm happy with comparisons to Holger Czukay.
thanx again for commenting, and i think your stuff would add more
variety to the source material on remix.linux. believe me - it *is* fun
... especially when someone remixes one of your own. i'm sure i can make
you laugh plenty hard still :D
shayne
Hi guys,
I have a RME HDSP9652 plus RME ADI-8 Pro under a FC3 PlanetCCRMA@Home distro
and I am experimenting some problems.
Kernel used is 2.6.10-3 with real time patch, and the distro is up to date.
I use rec_imp
(http://www.duffroomcorrection.com/wiki/Simple_Automated_IR_Measuring_Tool)
to measure my chain: I simple connect ADI-8 Pro input to output and analyse
the impulse response.
Well when first channel is used (i.e. input 0:0 output 0:0) results are
pretty good while using other inputs outputs results are really bad.
Basicly I have a lack in low frequency: looking at HDSPMixer I notice that
the input channel displays the signal only after some time the signal is
played on output. This should be the reason of lack of low frequency: the
impulse response is obtained by a logaritmic sine sweep test signal.
I contacted Ed Wildgooses (rec_imp creator), who supposed it could be a
driver problem: I was wondering if it is a known bug or someone had the same
problem.
Thanks!
Michele
Hi, everyone. This is my first time posting, so here's a quick introduction...
I've been using Linux since about 1998, but I only really started
using it on a regular basis in 2000. Since then I've been a sysadmin
and a user to varying degrees using Red Hat, then Mandrake, with a
brief (happy) stop in SUSE-land. I'm currently using Mandrake (10.1)
and I've started playing around with the friendlier Debian-derived
distros (Kubuntu, Kanotix, etc.).
Audio has never really been super-important for me, but I was always
annoyed when whatever distribution I was using failed to configure
sound properly. That hardly happens anymore, so I have very little
experience actually tweaking sound in any way. Anyhow, now not only
do I need to know Linux sound really well, but I need to be able to
construct a "pro sound" environment. It needs to be easy to use, too,
so the people running the studio don't have to think about the OS.
They just use their tools (Ardour, etc.) and get the job done. Fear
not. I'm not looking for hand-holding through the entire ordeal. I
can RTFM.
Here's the situation: I've been with the Toledo Area Linux Users
Group (http://talug.org) for several years now and some of us have
become involved with a local community effort called ToledoHipHop.org
(http://toledohiphop.org). They've already released one CD (CC
licensed, proprietary produced), but they want to put together their
own studio before starting to record the second and they want to do it
with Linux (they're philosophically down with the movement and the
freedom and all that). They've chosen a small room and there is a
team working on getting it ready. I'm on the team that is working on
the software-hardware components. We have three knowledgeable guys on
the studio recording side and a couple on the Linux side. We recently
had a visit from a nearby Linux audio guru who helped translate
between the two technical vocabularies and we're excited about getting
the project rolling. We're somewhat on our own, though.
We have a small budget (I don't know how much). The guys with studio
knowledge have looked at the linux-sound website and done some
searching and are asking whether they can use one of the following two
devices with Linux:
Tascam DM-300 (FireWire; new model)
Yamaha 01V96
So, for now all I'm looking for is advice about which device to
acquire that will give us a "pro sound" and relatively little trouble
on Linux for a meager budget.
Thanks in advance,
Jason
Quoting "Dmitry S. Baikov" <c0ff(a)konstruktiv.org>:
> > Depends on the laptop but possibly. Why so stringent about 64/2? Do
> > you _really_ require sub-3mS?
> >
> Processing live inputs better be done with lowest latency.
> Since 64/2 is only a part of total latency, increasing this value is
> noticable. Especially when playing guitar.
A little rudimentary math tells you that:
http://www.google.com/search?q=speed+of+sound+*+3+ms
In 3 milliseconds, the sound travels in air for 1.02 meters. Even if you go
to 4 times the latency (256x2), the time that your computer processes one
frame is faster than what the response time stadium rockers get from their gear.
Of course, this is all additive. If you're supposed to run things through
your computer and then onwards to a large stage, all extra latency will hurt.
Sampo
After much nailbiting, I've rebooted into a self-compiled kernel based on the
SuSE sources with the realtime-patch applied. The only other change I made
from the SuSE source was to change it from generic x86_64 to AMD64.
I had to recompile the NVidia and Atmel USB wireless modules, but once I was
up and running, I was able to start jack using qjackctl in RT mode. Haven't
had a huge amount of time to play with it, but looks good.
Weirdly, it wasn't this that was responsible for the sound artefacts I was
hearing as a user. After much frustrated investigation, I finally deleted
~/.qt/qjackctlrc and suddenly hydrogen sounds more like a drumkit than a
duck!
Thanks to everyone who responded to my posts.
--
David Haggett
Time to stick my heart on my sleeve I guess!
Instrumental only...Titled "Sunday Arvo" Why....er...Cause it was
recorded on a Sunday arvo! I did this back in Ardour Beta 28 I think in
about 3 hrs. Very simple and lots of rough edges.
Song is posted in Mp3 (sorry) format on the LAM page as well as here...
http://hanaghan.mystarband.net/Sunday%20Arvo.mp3
Let me know what you think.
R~
I hope it get's through this time...
On Wed, Sep 28, 2005 at 07:23:25PM +0200, Antonio wrote:
> Hi to the list,
>
> I've a problem starting jackd from a a normal user. I'm on debian
> testing and even using non-realtime mode I got this message:
>
> $ jackd -dalsa
> jackd 0.100.0
> Copyright 2001-2005 Paul Davis and others.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
>
> JACK compiled with System V SHM support.
> cannot create /dev/shm/jack-1000 directory (Permission denied)
>
> cannot create server sockets
> cannot create engine
> $ _
>
Hello.
As Mark Knecht has already pointed out, this is a permission issue. I am
using Debian unstable (with udev) and for me it looks like this:
~: ls -lhd /dev/shm/
drwxrwxrwt 3 root root 60 2005-09-28 22:50 /dev/shm/
Eventually installing udev (apt-get install udev) will fix the problem.
Or you can simply set the permissions with chmod.
Burkhard
> Shared memory is not the highest performance alternative in any
> operating system. When the video memory is part of system memory then
> the processor the video controller fight for memory bandwidth. This
> slows both down.
>
>>
>> So, the question is: what to choose, integrated intel solution or
>> ati/nvidia one (in this case, nvidia is preferred, because of driver
>> quality).
>>
>
> Choose a good controller with a bit of dedicated video memory. For
> purely audio apps you don't need all that much, but if you're going to
> run video apps or do multimedia stuff then you'll want more.
>
It's hard to find light laptop with dedicated controller at a reasonable
price :)
Is it possible to do 8in/8out and 64-sample buffers with RME Multiface
CardBus on a laptop with shared video memory?
And the only one(and expensive one) I found is with nvidia controller
(Sony Vaio VGN-S480). Not sure about nv TurboCache - is it a shared
memory solution?
Seems i want too much to be in one unit.