> I just sold mine on Ebay this morning. (At least I think it wasn't
> shared memory. Hardly remember anymore. Anyway, it's gone...)
It's not that easy to get anything to Russia :)
>
>> Is it possible to do 8in/8out and 64-sample buffers with RME Multiface
>> CardBus on a laptop with shared video memory?
>
> 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.
>
> Possibly, but even shared memory probably won't kill you if you're
> just running Ardour, etc.
>
I hope it will not kill me for running some live processing stuff -
SooperLooper, Jack-rack, etc.
I am on a FC4 host using audacity v1.2.3-5.2, build Aug, 2005, on a KDE
desktop. Today, when I opened a WAV file for editing and used the zoom-in
icon the cursor goes to the end of the audio and will not return. This
prevents me from viewing the area of the track playing when I need to edit.
I am relatively sure that I have not made changes to the OS that would cause
this behavior with the cursor and zoom-in.
Do anyone know what could possibly be going on?
Thanks
Flash
Many good opinions on RME...
Another question about Multiface.
Does it make sense to go cheap and buy CardBus->PCI controller and use
RME CardBus on both desktop and laptop instead of additional RME PCI
controller? Will this work? Yes, it's an additional bridge, but laptops
have it anyway and it does not hurt performace...
Still no FA-101 facts... Is anyone using it? Or only FreeBob developers
are brave enough? :)
Okay, any FireWire solution exerience will help. Please!
Thank you.
Dmitry.
On 9/28/05, *Paul Davis* <paul(a)linuxaudiosystems.com
<mailto:paul@linuxaudiosystems.com>> wrote:
> Is it possible in practice? And for what number of channels? Also,
is FW
> much better than USB2 and why?
yes, its much better: vastly higher bandwidth, much faster bus clock.
Theoretical(!) numbers are: FW-400 = 400MBits/s, USB2.0 = 480 MBits/s
> As for RME Multiface
i'm not sure that its that hard anymore. kernel 2.6 seemed to have fixes
...
--p
As I see, you insist on RME :) Reasonable choice. More expensive, but
bullet-proof.
From reading RME mailing lists, I know there were many problems with
Ricoh controllers (on PCI bursts). And everybody recommends TI. But most
notebooks to choose from have Ricoh controllers. Do you know if these
problems were solved? According to the list everybody went for Fireface
now, so there's no feedback on modern cardbus setups.
And even less on linux setups.
Questions about FA-101 still remain :)
More opinions / experiences are welcome :)
Thank you.
Dmitry.
Anyone try this yet? Ingo suggested off line that it should build for
AMD64 but it failed for me.
Just curious. If it does build I'd like to compare notes offline.
Cheers,
Mark
Hello!
I'm in the process of choosing mobile audio interface for both live sets
and studio recording.
I need minimal possible latency and 8x8 analog I/O.
The two from Edirol - FA-101 ($680) and UA-101($600) look promising, but
I'd like to hear about personal experience.
UA-101 is an USB 2.0 interface. AFAIU it imposes 1ms buffers, and 3
buffers setup in jackd. So, it should give 3ms minimal latency (but at
48 & 96 kHz only).
Is it possible in practice? And for what number of channels? Also, is FW
much better than USB2 and why?
As for FW solution, FreeBob project's site states FA-101 works, but I'd
like to know about minimal possible latency. And does it have any
restrictions on buffers/frequency setup?
As for RME Multiface ($700) + Cardbus ($390) (for notebook) + PCI ($300)
(for desktop), it's much more expensive solution, and AFAIK it's hard to
find notebook with appropriate PCMCIA controller to get 64-sample
(minimal) buffers to work reliable.
If there are better options, I'd like to hear about them also.
Thank you.
Best regards,
Dmitry.
P.S. Prices are for Russia, where I live.
> thats not a very fair comparison. USB2.0 is the "new USB", FW800 is the
> "new FW" :) but FW is also a better protocol, which means its easier to
> get close the theoretical maximum than it is with USB.
>
Fair enough, given USB2.0 and FW400 in most of laptops. And UA-101 is a
USB2 device (though, has no driver support yet)
Anyway, I'm interested in practical applications, not a theoretical ones.
> if you were in the US, i could offer you the best prices on RME gear
> (i'm a dealer), but with a european location, thats not likely.
>
Thank you, Paul. I also know where the linux drivers come from ;)
Dmitry.
On Wed, 2005-09-28 at 17:32 +0400, Dmitry Baikov wrote:
>
> yes, its much better: vastly higher bandwidth, much faster bus
> clock.
>
> Theoretical(!) numbers are: FW-400 = 400MBits/s, USB2.0 = 480 MBits/s
thats not a very fair comparison. USB2.0 is the "new USB", FW800 is the
"new FW" :) but FW is also a better protocol, which means its easier to
get close the theoretical maximum than it is with USB.
> >From reading RME mailing lists, I know there were many problems with
> Ricoh controllers (on PCI bursts). And everybody recommends TI. But
> most notebooks to choose from have Ricoh controllers. Do you know if
i have ENE controllers in my two HP laptops, as do a couple of other
people on LAD. there *were* problems with these in the 2.4 kernel
series, but they were fixable from user-space *and* are gone in 2.6
(AFAICT).
if you were in the US, i could offer you the best prices on RME gear
(i'm a dealer), but with a european location, thats not likely.
--p
Hi there,
I have a newish AMD64 machine. NForce4 chipset. Asus A8N-E
motherboard. PCI-Express 16x graphics, etc. No matter what I try I've
been constantly stopped from building a 2.6.13 kernel with Ingo's rt14
patch.
Here's the error message:
AS arch/x86_64/lib/copy_user.o
AS arch/x86_64/lib/csum-copy.o
CC arch/x86_64/lib/csum-partial.o
CC arch/x86_64/lib/csum-wrappers.o
CC arch/x86_64/lib/dec_and_lock.o
CC arch/x86_64/lib/delay.o
AS arch/x86_64/lib/getuser.o
AS arch/x86_64/lib/putuser.o
AS arch/x86_64/lib/thunk.o
CC arch/x86_64/lib/usercopy.o
AR arch/x86_64/lib/lib.a
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o(.text+0x24acc): In function `acpi_processor_idle':
: undefined reference to `tsc_c3_compensate'
make: *** [.tmp_vmlinux1] Error 1
lightning linux #
The 2.6.13 kernel builds fine before I apply the patch but fails afterward.
I do not find the error message
undefined reference to `tsc_c3_compensate'
in Google so maybe it's just me and my kernel config. I've attached
the config file zipped. I've tried some obvious stuff like completely
disabling ACPI, etc., but I haven't found anything that works yet.
Thanks in advance for any ideas. This has held up my new AMD64 machine
being useful
for a few weeks now.
NOTE: I have tried other realtime kernels like ck-sources but so far I
am having xrun problems. Possibly there is someone here successfully
using this motherboard? If so please contact me on-line or off with
info on your setup.
Cheers,
Mark
> Date: Sun, 25 Sep 2005 14:29:22 -0700
> From: Russell Hanaghan <hanaghan(a)starband.net>
> Subject: [linux-audio-user] Simple song in Ardour...
> To: A list for linux audio users <linux-audio-user(a)music.columbia.edu>
> Message-ID: <433716B2.1080702(a)starband.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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~
Hi Russell,
Nice track. Open, honest & simple. A keeper.
Thanks for sharing your work,
Gavin.