jump to beginning show previous Showing Logic-users Thread 98103 of 105816 show next jump to end

Forum Index | Read LUG: Policy/Rules Messages Threads Digests | Post New Message | Search!

From: Zip Boterbloem <zip@knoware.nl>
Date: Thu, 9 Nov 2006 at 6:25:51 AM
Subject: [LUG] Re: [GEN] Save CPU by running at 16 bit?
Message #220858
> > > >> The thing is I can play it live > >> without clicks or pops at 128 sample buffer using internal audio > outs > >> but plug in any Firewire audio interface and clicks and pops and > hung > >> notes occur... > > > > You might try another cable. > > Thanks Peter. I'm pretty sure I've done that. Is it actually possible > that the FW cable could work - but only intermittently? Same problems here with the EVB3. It's a processor hog. A MOTU interface might just work, just as a Metric Halo. But it will be on the edge. Best, Zip Boterbloem Media Mechanics Zwaluwstraat 54 2025 VR Haarlem The Netherlands +31627014758 zip@knoware.nl
Viewed 275 times, 1 reply, 8 messages in thread. Reply to this message.
From: Paul Najar <pnajar@bigpond.net.au>
Date: Thu, 9 Nov 2006 at 6:22:13 PM
Subject: Re: [LUG] Re: [GEN] Save CPU by running at 16 bit?
Message #220868
This is a reply to #220858.
On 09/11/2006, at 11:25 PM, Zip Boterbloem wrote: > Same problems here with the EVB3. It's a processor hog. A MOTU > interface might just work, just as a Metric Halo. But it will be on > the edge. Thanks Zip. After our other conversations about 128 sample buffers and firewire interfaces you would definitely know what you're talking about here since you've tried all the main contenders... I suppose I should try the FireBox on my Dual 2GHZ G5 Studio machine to see if the faster machine could handle it. If I knew it would take care of it I would upgrade to a Mac Book or Mac Book Pro. I'm simply playing one virtual instrument from midi. Logic is not even in playback. Of course I have no such trouble on the G5 running it's RME Multiface PCI - but now I've gone full circle. For no particular reason I don't trust that the faster Laptop would fix this issue though. Care to comment on that? Kind regards ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com
Viewed 252 times, 1 reply, 8 messages in thread. Reply to this message.
From: "Sascha Franck" <S.Franck@gmx.de>
Date: Fri, 10 Nov 2006 at 7:19:52 AM
Subject: Re: [LUG] Re: [GEN] Save CPU by running at 16 bit?
Message #220876
This is a reply to #220868.
Paul Najar wrote: > For no particular reason I don't trust that the faster Laptop would > fix this issue though. Care to comment on that? Paul, fwiw, I'm running a Macbook (2.0GHz, 2GB RAM) with an M-Audio FW410 at 64 samples all throughout. It's working absolutely great and the additional internal (non-documented) "safety buffers" all cards are adding don't seem to add too much either. Haven't done any scientific tests yet, but as I'm a guitarist mainly, I even need to do software audio monitoring - and I'm rather picky at all sorts of additional latency. With the FW410 things are really working nice. Having said that, I can of course run the EVB3 at those settings as well. No clicks and pops or whatsoever at all for me. Now, the FW410 might not be the shiniest card on earth, but M-Audio really seems to have gotten their driver act together. So far it's absolutely rock stable as well. Oh, and it only needs bus power, too. Quite a nice thing. Regards Sascha
Viewed 262 times, 1 reply, 8 messages in thread. Reply to this message.
From: Paul Najar <pnajar@bigpond.net.au>
Date: Fri, 10 Nov 2006 at 5:00:11 PM
Subject: Re: [LUG] Re: [GEN] Save CPU by running at 16 bit?
Message #220887
This is a reply to #220876.
On 11/11/2006, at 12:19 AM, Sascha Franck wrote: > Paul Najar wrote: >> For no particular reason I don't trust that the faster Laptop would >> fix this issue though. Care to comment on that? > > Paul, fwiw, I'm running a Macbook (2.0GHz, 2GB RAM) with an M-Audio > FW410 at > 64 samples all throughout. Wow! > It's working absolutely great and the additional internal (non- > documented) > "safety buffers" all cards are adding don't seem to add too much > either. > Haven't done any scientific tests yet, but as I'm a guitarist > mainly, I even > need to do software audio monitoring - and I'm rather picky at all > sorts of > additional latency. With the FW410 things are really working nice. > > Having said that, I can of course run the EVB3 at those settings as > well. No > clicks and pops or whatsoever at all for me. > Now, the FW410 might not be the shiniest card on earth, but M-Audio > really > seems to have gotten their driver act together. So far it's > absolutely rock > stable as well. > Oh, and it only needs bus power, too. Quite a nice thing. So clearly the faster machine is making a huge difference here. When I purchased my FireBox about a year ago I tried the FW410 as well and it was by far last in the "minimum buffer setting without clicks" stakes. In fact even at 256 samples the 410 performed worse than the FireBox at 128. Has there been many driver updates in the last 12 months? This is an encouraging report Sacha. It points to the fact that a faster powerbook will actually allow useful gains in the low latency stakes. I had my doubts but perhaps I was wrong... Kind regards ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com
Viewed 233 times, 1 reply, 8 messages in thread. Reply to this message.
From: "Sascha Franck" <S.Franck@gmx.de>
Date: Fri, 10 Nov 2006 at 7:44:47 PM
Subject: Re: [LUG] Re: [GEN] Save CPU by running at 16 bit?
Message #220892
This is a reply to #220887.
Paul Najar wrote: > So clearly the faster machine is making a huge difference here. When > I purchased my FireBox about a year ago I tried the FW410 as well and > it was by far last in the "minimum buffer setting without clicks" > stakes. In fact even at 256 samples the 410 performed worse than the > FireBox at 128. Has there been many driver updates in the last 12 > months? Hi Paul, I think there's even been a firmware update. The FW410 I tried out at first didn't seem to have it installed, but then the driver installation took care of this automatically as well. I had already tried the very same one out on my mates G4 powerbook like a year ago or so - been pretty much dissapointed back then. There seemed to be a whole lot of safety buffering going on, it never felt even remotely tight, not even at 32 samples buffer size. But after that update everything was just working fine - same with the one I bought (from our fellow Peter Ostry, btw - many thanks!). > This is an encouraging report Sacha. It points to the fact that a > faster powerbook will actually allow useful gains in the low latency > stakes. I had my doubts but perhaps I was wrong... From the reports I've seen so far, most people seem to be quite happy indeed. I'm also running NI's Rig Kontrol on my Macbook, and it's performing quite nicely at 128 or 64 samples as well - and it's even USB "only". I'm not sure whether the faster machine or the new chipset architecture is responsible for the proper performance, but in the end, I couldn't care less as long as it's working fine ;-) > I'll also add that in the case of Firewire > devices there are two kinds. [...] > My Presonus FireBox uses OS X's built in drivers. Huh! They really don't manage to develop their own drivers at Presonus? That *might* explain quite something. Assuming that parts of the internal OSX drivers might be responsible for those rather large additional latency that, say, the internal hardware is introducing, the dilemma could as well be "ported" to the Firebox. > One user reports stable performance at 64 samples on device X, > another user reports worse performance on device Y at same buffer > which makes us think X is better in this way but X may have 3 times > the safety buffer as Y which means Y would yield better effective > latency at double the sample buffer even though this is not apparent > on face value. Defenitely. The best experience being the internal interface of my Macbook. Which actually *is* performing fine, even at 32 samples. But the actual real-life latency figures aren't even remotely close to what you'd expect from 32 samples. I only learned about those "safety buffers" (or whatever they may be called officially) not too long ago. Well, ok, having configured quite some PC systems for DAW useage, I experienced them before as well, but I didn't exactly know it could be that much of a difference until I started doing exact in-to-out latency measurements myself. I actually felt like being cheated on some occasions. In these days, low latency performance (by sheer numbers) seems to be possible on a lot of more or less recent systems, so I think it's about time that hardware companies should actually release the real latency figures. Ok, maybe they won't, for business reasons, but at least magazines should do real-life performance tests, rather than writing something such as "performs well with 64 samples buffer size" - which indeed doesn't seem to mean anything. Regards Sascha
Viewed 246 times, 1 reply, 8 messages in thread. Reply to this message.
From: Paul Najar <pnajar@bigpond.net.au>
Date: Fri, 10 Nov 2006 at 9:01:38 PM
Subject: Re: [LUG] Re: [GEN] Save CPU by running at 16 bit?
Message #220893
This is a reply to #220892.
On 11/11/2006, at 12:44 PM, Sascha Franck wrote: > I think there's even been a firmware update. The FW410 I tried out > at first > didn't seem to have it installed, but then the driver installation > took care > of this automatically as well. > I had already tried the very same one out on my mates G4 powerbook > like a > year ago or so - been pretty much dissapointed back then. There > seemed to be > a whole lot of safety buffering going on, it never felt even > remotely tight, > not even at 32 samples buffer size. > But after that update everything was just working fine - same with > the one I > bought (from our fellow Peter Ostry, btw - many thanks!). When I did my tests I tried the FW410, my FB & a MOTU Traveller. Latency wise the MOTU performed best followed closely by the FB and then a large margin to the FW410. Sound quality wise was the same. MOTU & FB were close and the 410 was noticeably more dull sounding > I'm not sure whether the faster machine or the new chipset > architecture is > responsible for the proper performance, but in the end, I couldn't > care less > as long as it's working fine ;-) There has been so many questions cast over the Firewire bus architecture & audio that perhaps this may be where the Intel Mac crop has had improvement also? > Huh! They really don't manage to develop their own drivers at > Presonus? > That *might* explain quite something. Assuming that parts of the > internal > OSX drivers might be responsible for those rather large additional > latency > that, say, the internal hardware is introducing, the dilemma could > as well > be "ported" to the Firebox. Presonus use the term "Class Compliant" to describe this state. I didn't understand the difference when I did my tests even thought I did have to install drivers to try the MOTU and 410 at the time. Anyway it's been pretty good so far. It is a fine sounding interface and is useful as a standalone stereo input. It's converters are as good as my RME Multiface - maybe a hint better. It's software control panel is basic at best but then I'm a huge fan of the RME Totalmix setup on my main studio computer. Months after I bought it MOTU came out with their Ultralite and I was tempted to switch but it was still a fair bit more expensive so I couldn't be bothered... > Defenitely. The best experience being the internal interface of my > Macbook. > Which actually *is* performing fine, even at 32 samples. But the > actual > real-life latency figures aren't even remotely close to what you'd > expect > from 32 samples. By far this has been my experience also in part I think because Firewire audio does have a CPU hit for sure. > In these days, low latency performance (by sheer numbers) seems to be > possible on a lot of more or less recent systems, so I think it's > about time > that hardware companies should actually release the real latency > figures. Honesty in capitalistic pursuit? It's hardly ever likely. A bit too environmentally sound perhaps... > Ok, maybe they won't, for business reasons, but at least magazines > should do > real-life performance tests, rather than writing something such as > "performs > well with 64 samples buffer size" - which indeed doesn't seem to mean > anything. The magazines - to a fair extent only exist because the companies building the products advertise their wares and so are tarred with the same brush as well... Kind regards ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com
Viewed 223 times, 1 reply, 8 messages in thread. Reply to this message.
From: "Sascha Franck" <S.Franck@gmx.de>
Date: Sat, 11 Nov 2006 at 4:27:05 AM
Subject: Re: [LUG] Re: [GEN] Save CPU by running at 16 bit?
Message #220901
This is a reply to #220893.
Paul Najar wrote: > Sound quality wise was the same. > MOTU & FB were close and the 410 was noticeably more dull sounding Yeah, I know the FW410 isn't the shiniest card on earth. But then, for my mobile needs it's almost perfect (if a bit large), especially as it's got all the inputs I need and two headphone outs (truly great for a bit of a late nite hotel room jam with some bass player or so). > There has been so many questions cast over the Firewire bus > architecture & audio that perhaps this may be where the Intel Mac > crop has had improvement also? Not so sure yet, but it's at least working way better than on my PC-laptop (which sometimes is sort of freezing in, so I can't use the 410's routing software anmore). > By far this has been my experience also in part I think because > Firewire audio does have a CPU hit for sure. Hm, I'm constantly reading about this as well. Now, as I only have a Macbook, I can't compare to whatever PCI solution 1:1, but I've been quite amazed being able to run some CPU stress song (multiple ES2 with multiple platinum verbs added) just as fine through the FW410 as through the internal hardware. It seems that on modern machines, the additional CPU hit introduced by FW and USB doesn't seem to be that much noticeable anymore. Whether this is simply caused by CPUs getting faster and faster or by better FW/USB ports - I wouldn't happen to know. But in the end, who cares, as long as it's working all fine? > The magazines - to a fair extent only exist because the companies > building the products advertise their wares and so are tarred with > the same brush as well... Yeah, I know. Too bad though. I mean, seriously, chosing an audio interface is one of *the* most critical tasks when setting up a DAW. It's not like a plugin, which you may not like as much as a reviewer, it's not like a compressor, an EQ or whatever either (even if you may pay quite a lot more for them), it's one of the essentials in whatever studio setup, and as a result of that, a large part of your working fun is depending on it. Which is becoming even more true once you have to deal with software monitoring. Regards Sascha
Viewed 236 times, 1 reply, 8 messages in thread. Reply to this message.
From: Paul Najar <pnajar@bigpond.net.au>
Date: Sat, 11 Nov 2006 at 11:37:14 PM
Subject: Re: [LUG] Re: [GEN] Save CPU by running at 16 bit?
Message #220922
This is a reply to #220901.
On 11/11/2006, at 9:27 PM, Sascha Franck wrote: > I mean, seriously, chosing an audio interface is one of *the* most > critical > tasks when setting up a DAW. It's not like a plugin, which you may > not like > as much as a reviewer, it's not like a compressor, an EQ or > whatever either > (even if you may pay quite a lot more for them), it's one of the > essentials > in whatever studio setup, and as a result of that, a large part of > your > working fun is depending on it. Which is becoming even more true > once you > have to deal with software monitoring. So true Sacha. Amongst my activities I lecture in electronic music production. One off the most difficult lessons to impart is in choosing an audio interface because no matter how honest I am it's a very complex set of principals for a young guy starting out to get. And no matter what I tell them they will still go to a shop and some young sales guy who often knows less then the guy buying sells them a device that will never be what they should have bought but it will be what the shop guy needs to move and that's all. And the reason they have the junk interface in stock is because the same manufacturer makes other products which are great but to carry the brand the shop is forced to carry a minimum range of the brand's products.... Ah well. If this stuff was easy everybody would be making a living from it. Kind regards ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com
Viewed 227 times, 0 replies, 8 messages in thread. Reply to this message.

Forum Index | Read LUG: Policy/Rules Messages Threads Digests | Post New Message | Search!

Forum Index | Read LUG: Policy/Rules Messages Threads Digests | Post New Message | Search!


© 1994-2008, All Rights Reserved.