| Home |
| Search |
| Today's Posts |
|
#1
Posted to rec.audio.pro
|
|||
|
|||
DICE II Firewire Driver Settings
I have an Allen & Heath Zed R16 here for review. Great sounding and
feeling mixer (built like a real mixer, too) but its digital part doesn't seem to be very happy with my computer (which works fine with a Mackie Onxy 1200F). It snaps, crackles and pops even when playing two channels, it gets worse with time, and eventually the driver loses communication with the mixer and it has to be reset. The driver control panel has a "Normal" setting as well as Safe Modes 1, 2, and 3. No explanation of what those do, but it seems to work worst in Normal and better in the Safe modes. I haven't been able to find any significant public information on the DICE II chip other than press releases. Anyone have experience with those Safe modes or have a product with a DICE that says something about them in the manual? The computer is pretty well optimized with all the standard Windows settings. Setting the buffer to 512 samples seems to work a little better but it doesn't get any better with a larger or smaller buffer. I'm not worried about latency (yet), I'd just like to be able to get a few hours of mixing time on it to get a feel for it without having to put up with all that hash and eventual silence. It's the weekend, so I haven't tried to contact A&H yet. I'm afraid that it's one of those things where the Firewire chip in my computer isn't the best match for the one in the mixer. The card in the computer has a VIA chip which most people will tell you doesn't work with anything (but I can tell you that it works fine with Mackie's stuff). I have a PCMCIA adapter for my old laptop computer (NEC chip in that one) and I think it works better than the studio computer when playing stereo tracks through the Zed, but that laptop doesn't really have enough horsepower to play more than about 6 tracks so it's not a fair comparison. Tired of screwing with it for the day, but I was just wondering if anyone knows what that "Safe Mode" is and whether it's really meant to make it work better under some conditions. -- If you e-mail me and it bounces, use your secret decoder ring and reach me he double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers ) |
|
#2
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Sat, 08 Nov 2008 21:30:17 +0000, Mike Rivers wrote:
I have an Allen & Heath Zed R16 here for review. Great sounding and feeling mixer (built like a real mixer, too) but its digital part doesn't seem to be very happy with my computer (which works fine with a Mackie Onxy 1200F). It snaps, crackles and pops even when playing two channels, it gets worse with time, and eventually the driver loses communication with the mixer and it has to be reset. The driver control panel has a "Normal" setting as well as Safe Modes 1, 2, and 3. No explanation of what those do, but it seems to work worst in Normal and better in the Safe modes. I haven't been able to find any significant public information on the DICE II chip other than press releases. Anyone have experience with those Safe modes or have a product with a DICE that says something about them in the manual? The safe modes are to mitigate problems when other drivers (for video, usb etc) spend too much time in a DPC call, and the kernel cannot run the soundcard driver in time for it to service the audio buffers. They solve this by using larger kernel side buffers = increased latency. The larger buffer size means there can be a longer delay before the driver runs. I imagine the latency gets longer with the higher safe modes. So, some other driver on your system is not real time safe, or else perhaps a driver has made a non preemptable system call that must be carried out before another driver can run. I learnt most of this from he http://www.gearslutz.com/board/low-e...s-i-o-konnekt- firestudio-dice-ii-chipset-interfaces.html and don't fully understand it. The difference between the kernel side buffers and the normal audio ones is that the audio buffers affect how many samples are in each buffer that is sent to the soundcard, thus a larger buffer means less interrupts so each interrupt is more likely to be serviced in time. A larger driver kernel buffer affects how long another driver can spinlock before the sound card driver must run. I don't understand why the safe modes work, as if the kernel is spinlocked, surely it will miss the sound card's interrupt too? The computer is pretty well optimized with all the standard Windows settings. Setting the buffer to 512 samples seems to work a little better but it doesn't get any better with a larger or smaller buffer. I'm not worried about latency (yet), I'd just like to be able to get a few hours of mixing time on it to get a feel for it without having to put up with all that hash and eventual silence. It's the weekend, so I haven't tried to contact A&H yet. I'm afraid that it's one of those things where the Firewire chip in my computer isn't the best match for the one in the mixer. The card in the computer has a VIA chip which most people will tell you doesn't work with anything (but I can tell you that it works fine with Mackie's stuff). I have a PCMCIA adapter for my old laptop computer (NEC chip in that one) and I think it works better than the studio computer when playing stereo tracks through the Zed, but that laptop doesn't really have enough horsepower to play more than about 6 tracks so it's not a fair comparison. Tired of screwing with it for the day, but I was just wondering if anyone knows what that "Safe Mode" is and whether it's really meant to make it work better under some conditions. I had some initial problems with my DICEII based Presonus Firestudio. Not working well at low latency and the occasional glitch. Getting a new TI PCI firewire card improved matters. (And a VIA one too that did not work so well.) |
|
#3
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
philicorda wrote:
The safe modes are to mitigate problems when other drivers (for video, usb etc) spend too much time in a DPC call, and the kernel cannot run the soundcard driver in time for it to service the audio buffers. Misnamed, I think, but that sounds like a reasonable thing to do to help people like me who don't know what a DPC call is and thinks a kernel is where popcorn starts. They solve this by using larger kernel side buffers = increased latency. The larger buffer size means there can be a longer delay before the driver runs. I imagine the latency gets longer with the higher safe modes. So, some other driver on your system is not real time safe, or else perhaps a driver has made a non preemptable system call that must be carried out before another driver can run. So, is there anything I can do about this that will make it work better other than to slow it down? I'll check out that Gearslutz reference to see if there's anything I can use there. I may have actually run across that in my Googling, but most of what I saw about the DICE was about the Alesis I/O thing so I passed it up. The Zed is probably too new for anyone to start talking about it yet. The difference between the kernel side buffers and the normal audio ones is that the audio buffers affect how many samples are in each buffer that is sent to the soundcard, thus a larger buffer means less interrupts so each interrupt is more likely to be serviced in time. A larger driver kernel buffer affects how long another driver can spinlock before the sound card driver must run. I thought that Firewire was supposed to mitigate problems like that because of its smarts to keep data flowing. At least that's one of the arguments that people use in the Firewire vs. USB2 wars. I had some initial problems with my DICEII based Presonus Firestudio. Not working well at low latency and the occasional glitch. Getting a new TI PCI firewire card improved matters. (And a VIA one too that did not work so well.) Yeah, that's one of the standard Firewire audio fix-its. Whatever Firewire I/O card you have, get something different. g It's getting harder to tell what chipset a particular card uses though. They used to put that info on the box sometimes, now you don't always even get a box. And the hardware manufacturers don't necessarily use the same parts this year that they used last year. So if someone who bought a Brand A card a couple of years back and found (by checking it in the Windows Device Manager) that it had a TI chip tells you to get one like it, unless you buy one just as old, there's no guarantee that you'll get the chip you're looking for. When I got the Mackie Onyx mixer card, my first Firewire audio deveice, I didn't have a Firewire card in any of my computers. My laptop was the most powerful one at the time, so I got a PCMCIA adapter for it. Got clicks and pops, so I exchanged it for a different brand, and then a third one, until I finally found the noises were related to the network card. A new driver for that fixed the problem, and I suspect that any of the Firewire cards I had would have worked fine. -- If you e-mail me and it bounces, use your secret decoder ring and reach me he double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers ) |
|
#4
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
Mike Rivers wrote:
Misnamed, I think, but that sounds like a reasonable thing to do to help people like me who don't know what a DPC call is and thinks a kernel is where popcorn starts. You are SUCH an old fart. Nowadaze everyone knows popcorn starts with a microwave! "I guess the times have changed, kids are different now, "'Cause some don't even seem to know the milk comes from a cow. "My little boy can tell the names of all the baseball stars, "I remember how we memorized the names on railroad cars" Utah Phillips (I've been splitting wood all day and seem to be infected with off-topicness.) -- ha shut up and play your guitar |
|
#5
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
Soundhaspriority wrote:
I tried to find some programming information that I could interpret for you, but I found nothing. I don't think the explanation is completely correct. All ASIO buffers are in the kernel. "Kernel side buffers" is borrowed terminology from Linux. The way this field works, people coin and borrow new terms all the time. There's nothing wrong with this, but I can't find a correspondence between the term and a programming scenario. However, there are separate buffers set up by the firewire driver. They're all in the kernel, along with the ASIO buffers. Well, thanks for the effort, but the bottom line, as I see it, is that whatever the explanation, there's absolutely nothing we can do to fix it other than to try different hardware and see if that works any better. There's nothing you can test and then repair. I try to look at the best Firewire can do, not the worst. The fact is, there is no other even semi generic alternative that provides anywhere near the performance. Better alternatives exist in proprietary forms. Apogee, Emu, RME, and Motu all offer proprietary alternatives. The bottom line is that all of this stuff can work. Manufacturers don't intentionally make defective products. But since they're trying to work in the world of open systems and can't possibly test every combination, they (and we) have to accept that there will be combinations that don't work very well. It's the responsibility that we take on by not paying for the engineering and testing of a turnkey system. The majority of the users get satisfactory operation, the others jump on to forums and complain about poor designs and inadequately tested drivers. If there is information that allows someone to predict success with reasonable certainty -- such as using an Echo product instead of this, it's a plus. If I were you, and had the responsibility of a reviewer, I would call up Allen and Heath, and find out exactly what adapter chipset they engineered to. Ifthat chipset is a $50 proposition, it's not a drawback. For the purpose of a review, it really doesn't matter. It works well enough so that I can say that (when it works) it sounds good and go on to describe the functionality and features. If I wanted to buy it, I'd certainly make an attempt to find the optimum interface hardware. The thing is that as a reviewer, I don't work like an ordinary person who gets a hardware setup and works with it for a couple of years. If I have to change a card to get the A&H to work, then change to another card to get the Mackie to work, then another card to get a Personus to work, and another card to get a t.c. to work . . . Then I get an RME and find that it works fine with the last Firewire card I put in the computer, so I get curious and put in another one and it works, and I put in a third one and it works . . . . I need to say something about this. All arbitrary of course, for the sake of this discussion, but "I tried Brand X and I couldn't get it working so I bought a Brand R and it worked right off" seems to be pretty common. So what do they know that the others don't? think that they should loan you a card so as to give the product the best chance, or possibly you might decline to review. If you get "their" card, and it still doesn't work, serious reservations may be in order. Well, maybe, but they don't know what else is on and in my computer. For the best review, they should lend me a computer that they've tested. And that gets back to the turnkey engineering. An important part of a review SHOULD be how well they've dealt with the "it should work with whatever the customer has" aspect. But that's a really tough assignment. I feel for them. -- If you e-mail me and it bounces, use your secret decoder ring and reach me he double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers ) |
|
#6
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 8, 10:24 pm, Mike Rivers wrote:
Soundhaspriority wrote: I tried to find some programming information that I could interpret for you, but I found nothing. I don't think the explanation is completely correct. All ASIO buffers are in the kernel. "Kernel side buffers" is borrowed terminology from Linux. The way this field works, people coin and borrow new terms all the time. There's nothing wrong with this, but I can't find a correspondence between the term and a programming scenario. However, there are separate buffers set up by the firewire driver. They're all in the kernel, along with the ASIO buffers. Well, thanks for the effort, but the bottom line, as I see it, is that whatever the explanation, there's absolutely nothing we can do to fix it other than to try different hardware and see if that works any better. There's nothing you can test and then repair. I try to look at the best Firewire can do, not the worst. The fact is, there is no other even semi generic alternative that provides anywhere near the performance. Better alternatives exist in proprietary forms. Apogee, Emu, RME, and Motu all offer proprietary alternatives. The bottom line is that all of this stuff can work. Manufacturers don't intentionally make defective products. But since they're trying to work in the world of open systems and can't possibly test every combination, they (and we) have to accept that there will be combinations that don't work very well. It's the responsibility that we take on by not paying for the engineering and testing of a turnkey system. ... Well, maybe, but they don't know what else is on and in my computer. For the best review, they should lend me a computer that they've tested. And that gets back to the turnkey engineering. An important part of a review SHOULD be how well they've dealt with the "it should work with whatever the customer has" aspect. But that's a really tough assignment. I feel for them. Hank fell two oaks out in the horse pasture, it is coming into that season!! you can tell as mike is bitchin' about firewire and his cheap computers. I am thinking that I need to buy a hydraulic splitter, the muscles are not happy. mike will it work with a mac the newest mac book pro's are the cat's meow. |
|
#7
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 8, 10:24 pm, Mike Rivers wrote:
Soundhaspriority wrote: I tried to find some programming information that I could interpret for you, but I found nothing. I don't think the explanation is completely correct. All ASIO buffers are in the kernel. "Kernel side buffers" is borrowed terminology from Linux. The way this field works, people coin and borrow new terms all the time. There's nothing wrong with this, but I can't find a correspondence between the term and a programming scenario. However, there are separate buffers set up by the firewire driver. They're all in the kernel, along with the ASIO buffers. Well, thanks for the effort, but the bottom line, as I see it, is that whatever the explanation, there's absolutely nothing we can do to fix it other than to try different hardware and see if that works any better. There's nothing you can test and then repair. I try to look at the best Firewire can do, not the worst. The fact is, there is no other even semi generic alternative that provides anywhere near the performance. Better alternatives exist in proprietary forms. Apogee, Emu, RME, and Motu all offer proprietary alternatives. The bottom line is that all of this stuff can work. Manufacturers don't intentionally make defective products. But since they're trying to work in the world of open systems and can't possibly test every combination, they (and we) have to accept that there will be combinations that don't work very well. It's the responsibility that we take on by not paying for the engineering and testing of a turnkey system. ... Well, maybe, but they don't know what else is on and in my computer. For the best review, they should lend me a computer that they've tested. And that gets back to the turnkey engineering. An important part of a review SHOULD be how well they've dealt with the "it should work with whatever the customer has" aspect. But that's a really tough assignment. I feel for them. Hank fell two oaks out in the horse pasture, it is coming into that season!! you can tell as mike is bitchin' about firewire and his cheap computers. I am thinking that I need to buy a hydraulic splitter, the muscles are not happy. mike will it work with a mac the newest mac book pro's are the cat's meow. |
|
#8
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
wrote in message
On Nov 8, 10:24 pm, Mike Rivers wrote: Soundhaspriority wrote: I tried to find some programming information that I could interpret for you, but I found nothing. I don't think the explanation is completely correct. All ASIO buffers are in the kernel. "Kernel side buffers" is borrowed terminology from Linux. The way this field works, people coin and borrow new terms all the time. There's nothing wrong with this, but I can't find a correspondence between the term and a programming scenario. However, there are separate buffers set up by the firewire driver. They're all in the kernel, along with the ASIO buffers. Well, thanks for the effort, but the bottom line, as I see it, is that whatever the explanation, there's absolutely nothing we can do to fix it other than to try different hardware and see if that works any better. There's nothing you can test and then repair. I try to look at the best Firewire can do, not the worst. The fact is, there is no other even semi generic alternative that provides anywhere near the performance. Better alternatives exist in proprietary forms. Apogee, Emu, RME, and Motu all offer proprietary alternatives. The bottom line is that all of this stuff can work. Manufacturers don't intentionally make defective products. But since they're trying to work in the world of open systems and can't possibly test every combination, they (and we) have to accept that there will be combinations that don't work very well. It's the responsibility that we take on by not paying for the engineering and testing of a turnkey system. ... Well, maybe, but they don't know what else is on and in my computer. For the best review, they should lend me a computer that they've tested. And that gets back to the turnkey engineering. An important part of a review SHOULD be how well they've dealt with the "it should work with whatever the customer has" aspect. But that's a really tough assignment. I feel for them. Hank fell two oaks out in the horse pasture, it is coming into that season!! you can tell as mike is bitchin' about firewire and his cheap computers. I am thinking that I need to buy a hydraulic splitter, the muscles are not happy. mike will it work with a mac the newest mac book pro's are the cat's meow. They tell me that a lot of the new Mac Books don't even have firewire ports. OK, the pro still has a firewire chip, but isn't this a sign that Apple is abandoning firewire? |
|
#9
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
Arny Krueger wrote: They tell me that a lot of the new Mac Books don't even have firewire ports. OK, the pro still has a firewire chip, but isn't this a sign that Apple is abandoning firewire? none of the most recent mac books have firewire. the mac book pro does. there are a lot of petitions to apple about this. I think that they are just getting ready for the newest firewire, 3.2 gig!! and it will be backwards compatible. |
|
#10
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Sun, 09 Nov 2008 00:24:51 +0000, Mike Rivers wrote:
philicorda wrote: The safe modes are to mitigate problems when other drivers (for video, usb etc) spend too much time in a DPC call, and the kernel cannot run the soundcard driver in time for it to service the audio buffers. Misnamed, I think, but that sounds like a reasonable thing to do to help people like me who don't know what a DPC call is and thinks a kernel is where popcorn starts. They solve this by using larger kernel side buffers = increased latency. The larger buffer size means there can be a longer delay before the driver runs. I imagine the latency gets longer with the higher safe modes. So, some other driver on your system is not real time safe, or else perhaps a driver has made a non preemptable system call that must be carried out before another driver can run. So, is there anything I can do about this that will make it work better other than to slow it down? I'll check out that Gearslutz reference to see if there's anything I can use there. This is the relevant part: "When developing a driver that can exhibit low audio latency there is a compromise between obtaining low latency and avoiding clicks every time another driver creates a large DPC spike. In the DICE drivers this is balanced by the €˜safe mode setting. Higher €˜safe mode makes the system less sensitive to DPC latencies (insensitive to anything below the €˜safe mode threshold) by relying on more buffering in the kernel and therefore more latency." I may have actually run across that in my Googling, but most of what I saw about the DICE was about the Alesis I/O thing so I passed it up. The Zed is probably too new for anyone to start talking about it yet. If using one of the safe modes improves matters, you could download a program called 'DPC Latency Checker': http://www.thesycon.de/deu/latency_check.shtml This will show you in microseconds the longest spinlock that the kernel is holding. The safe mode must make the buffers larger to deal with the time spent waiting for the lock to be released. There is a far better explanation on that page of the problem than mine. If there are long spinlocks, then it's back to magic spells and randomly disabling hardware until the errant driver is found. I'm sure there is an equivalent for 'latencytop' on Windows that will tell you exactly where the kernel is spending all it's time, rather than just that there is a problem. A Windows developer would know more about this. The difference between the kernel side buffers and the normal audio ones is that the audio buffers affect how many samples are in each buffer that is sent to the soundcard, thus a larger buffer means less interrupts so each interrupt is more likely to be serviced in time. A larger driver kernel buffer affects how long another driver can spinlock before the sound card driver must run. I thought that Firewire was supposed to mitigate problems like that because of its smarts to keep data flowing. At least that's one of the arguments that people use in the Firewire vs. USB2 wars. The firewire interface can use DMA to transfer data directly into memory, without utilising the CPU. Once the data is there though, the kernel mode sound card device driver still needs to run to process that data. If there is another driver ahead in the queue that is taking too long, then the data may not be processed before the sound card is ready to send it's next block. I had some initial problems with my DICEII based Presonus Firestudio. Not working well at low latency and the occasional glitch. Getting a new TI PCI firewire card improved matters. (And a VIA one too that did not work so well.) Yeah, that's one of the standard Firewire audio fix-its. Whatever Firewire I/O card you have, get something different. g It's getting harder to tell what chipset a particular card uses though. They used to put that info on the box sometimes, now you don't always even get a box. And the hardware manufacturers don't necessarily use the same parts this year that they used last year. So if someone who bought a Brand A card a couple of years back and found (by checking it in the Windows Device Manager) that it had a TI chip tells you to get one like it, unless you buy one just as old, there's no guarantee that you'll get the chip you're looking for. My guess is that changing the Firewire card a few times cleans the contacts in the PCI slot.  It could be that the hardware is irrelevant and what makes the difference is changing the device driver, or perhaps IRQs getting reassigned when you move hardware around. Or perhaps it really is just magic. I'd like some more authoritative explanations of all this stuff too, which is why I'm writing mine in the hope of making a *real* geek annoyed enough to correct me. When I got the Mackie Onyx mixer card, my first Firewire audio deveice, I didn't have a Firewire card in any of my computers. My laptop was the most powerful one at the time, so I got a PCMCIA adapter for it. Got clicks and pops, so I exchanged it for a different brand, and then a third one, until I finally found the noises were related to the network card. A new driver for that fixed the problem, and I suspect that any of the Firewire cards I had would have worked fine. It would be interesting to know if the network driver would have shown up on the DPC latency checker. |
|
#11
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
|
|
#12
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
|
|
#13
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
philicorda wrote:
My guess is that changing the Firewire card a few times cleans the contacts in the PCI slot. It could be that the hardware is irrelevant and what makes the difference is changing the device driver, or perhaps IRQs getting reassigned when you move hardware around. Or perhaps it really is just magic. I'll go for the magic. My Firewire card seems to be running on an ancient Microsoft driver. It says 7/1/2001 Ver. 5.1.2535.0. I tried looking for an update to that driver on the Microsoft support web site but there doesn't seem to be one. So the card is talking to the CPU the same way it was seven years ago. -- If you e-mail me and it bounces, use your secret decoder ring and reach me he double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers ) |
|
#14
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 9, 1:24 pm, Mike Rivers wrote:
....My point isn't that Firewire doesn't work for audio, i t's that there isn't yet sufficient standardization of interface components (including stuff inside the computer, I suspect) that any particular combination, of which there sure surely thousands possible, can't be assured of working flawlessly. It doesn't matter to the user (me, in this case) what the problem is until someone can give me a solution - not a "try this." solution given, buy a Mac Book Pro. no thousands of possibilities, it is your "turnkey" system. it works!!! which is why I laugh every time you restart this same thread! |
|
#16
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 9, 2:39 pm, Mike Rivers wrote:
but when you get new stuff in every couple of months that's "supposed" to work with the nominal system that I have, then, dammit, it SHOULD work. I'm not complaining about the DICE chip or the Zed mixer, I'm complaining about the perception of compatibility that isn't. I say the problem is you have the less expensive, older models of computers bought with the prime consideration of how little you would spend. You then try to hook something up to it that requires more then then your pieces of crap can deliver. Then you post here bellyaching about how it doesn't work right. Is this is how they do design and development, low bid. I wonder how long your patron's will tolerate your inability to work with their products? oh yeah, they really don't pay you, you take product as payment. sounds like payola, should one trust the reviewer who take payola and can not get the product to work properly? |
|
#17
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 9, 12:14 pm, philicorda
wrote: If using one of the safe modes improves matters, you could download a program called 'DPC Latency Checker': This will show you in microseconds the longest spinlock that the kernel is holding. The safe mode must make the buffers larger to deal with the time spent waiting for the lock to be released. There is a far better explanation on that page of the problem than mine. If there are long spinlocks, then it's back to magic spells and randomly disabling hardware until the errant driver is found. Interesting. The meter stays well down in the green, in the ballpark of 30 us range whether a file is playing or not, when using either the Mackie or Zed interface. The Mackie plays fine, the Zed is more hash than music. What I did note, however (and this might be some characteristic of the DPC checker) was that as soon as I closed Nuendo, it slammed all the way up to the top of the display and stayed there. I thought maybe it was that the audio interface (I was using the Mackie at the time) was desperately trying to find somebody to talk to, but turning it off didn't stop the high DPC usage even after a couple of minutes. Closing the DPC checker and restarted it showed all grean. |
|
#18
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
Mike Rivers wrote:
wrote: buy a Mac Book Pro. no thousands of possibilities, it is your "turnkey" system. Maybe it works now, but what about three years from now? I'm six years into using this TiBook. Mind you, I'm not a reviewer, so I don't get the joy of trying to get it to work with the newest and coolest stuff. Since the MIO works so damn well I have no desire or need to think of upgrading. Hell, Metric Halo has a lot of new action available for my interface, but I'm not going there until I can't keep this old Mac running. I replaced the HD five years in, and will soon replace the optical drive with one that burns DVD's. -- ha shut up and play your guitar |
|
#19
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
|
|
#20
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
hank alrich wrote:
Since the MIO works so damn well I have no desire or need to think of upgrading. Hell, Metric Halo has a lot of new action available for my interface, but I'm not going there until I can't keep this old Mac running. Since my Mackie HDR24/96 and Soundcraft 600 work so well together, I see no need in upgrading my personal system (no computers necessary). But I can't make the boat payments reviewing gear that nobody will buy today. -- If you e-mail me and it bounces, use your secret decoder ring and reach me he double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers ) |
|
#21
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
"Mike Rivers" wrote in message
wrote: I say the problem is you have the less expensive, older models of computers bought with the prime consideration of how little you would spend. You then try to hook something up to it that requires more then then your pieces of crap can deliver. Requires more WHAT? What's missing from my system that more money could buy (other than an Apple nameplate)? Well, its those Intel processors that Apple uses. No other PCs have them. Whoops! ;-) What does Apple know that others don't? Clearly at one time Apple understood Firewire better than everybody else. However, it is a canon of engineering that if you understand what you are doing, you can reduce what you are doing to plans, procedures, bills of material, design rules, and specs. You can then give them to other reasonably good people and they will duplicate what you did. If you can't do that, then you aren't much of an engineer, especially if you can't do it over a period of time that is as long as Apple has been pushing Firewire. So, either Apple are total incompetents who can't engineer worth squat, even when given a decade to get it right, or there's no magic to Apple firewire. ;-) |
|
#22
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 10, 7:39 am, Mike Rivers wrote:
wrote: I say the problem is you have the less expensive, older models of computers bought with the prime consideration of how little you would spend. You then try to hook something up to it that requires more then then your pieces of crap can deliver. Requires more WHAT? What's missing from my system that more money could buy (other than an Apple nameplate)? What does Apple know that others don't? Then you post here bellyaching about how it doesn't work right. But it DOES work right. I have three other Firewire audio interfaces that work just fine with this computer. The fact that the DICE-II chip wasn't in commercial products at the time that I bought the Firewire card that I put in this computer may be related to the problem. However, the Firewire specification and standards were in place when the DICE-II was developed. So why doesn't it work? I can only surmise that there's something that the DICE wants or needs that didn't exist a couple of years ago. The whole idea behind a computer-based SYSTEM is that things work together because every interface is designed to meet the standards for that interface. Now I recognize that standards evolve and the documentation and universal acceptance often comes along later, and this may be the case here. But "You need a Macbook Pro" doesn't guarantee that it won't be obsolete for the DICE-III or whatever comes along next. I'd be happy to plug this mixer into your Macbook Pro if you bring it over. That will provide ONE data point. Then we can plug my Onyx Satellite into your Macbook Pro and you'll see that it doesn't work. I wonder how long your patron's will tolerate your inability to work with their products? I do, too. I'm pretty smart, but I'm not rich. Some of their customers are the other way around and will gladly buy a new computer that's guaranteed to work with the new hardware they want. I call that a turnkey system, and that by purchasing this way, you're paying someone else to do the research, the worrying, the testing, and the integration. But much of the gear in the marketplace today is sold to people who are intent on doing their own system engineering - because they think they can, or that it's the only way they can afford the functionality that they want. oh yeah, they really don't pay you, you take product as payment. sounds like payola, should one trust the reviewer who take payola and can not get the product to work properly? This is bordering on libel. Watch it! I get paid for my reviews. I don't get given gear in exchange for reviews. And you're getting off the subject. I think you don't have the technical answers I'm seeking so you're just shooting the messenger. It doesn't help. There are lots of messengers, many of whom are less resourceful than I am. At least I'm trying to find out what the problem is so I can guide my readers toward getting a successful system. If the only computer it works with is a Macbook Pro, so be it. If the manufacturer tells me this, or recommends specific Firewire adapters and OS versions, I'll certainly pass that on. But from a Mac zealot who has never tried the product I'm testing, your blanket recommendation doesn't carry much weight with me. -- If you e-mail me and it bounces, use your secret decoder ring and reach me he double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers ) Mike should I do a search of this group and get a list of how many times you have posted about having problems with YOUR computer and the firewire interface for equipment you are trying to review? (earliest post Dec 29 2000 total #1660) or how about the article you were going to write and wanted resource material. (which I suppled many links for!) why does the apple product work ... good design with a build that is not looking for the cheapest price point. My research into a computer daw lead me to purchase the mac and metric halo products. this same research had me purchase plextor optical burners and a windows machine. I buy based on research and not some cult inspiration or how cheap I can buy it !!! I have given my advice in the past but you always disregard it unless Scot on Dan Lavery say the same thing. I would think that having 8 years of posting here about your lack of firewire understanding would have given you the tools needed but this new thread proves otherwise. |
|
#23
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
Dammit! It's getting better, or at least more interesting. If I change
anything in the DICE driver control panel - the buffer size or the Safe Mode setting (this is really complicated and I don't want to go into it, but there's a detailed - though I don't know how accurate - explanation of it on the Gearslutz forum) it plays fine for a while, and then gets progressively worse. I had left it playing in a loop while I went off to check the e-mail, and when I was walking back to the studio, I thought my neighbor was blowing his leaves in my back yard. It was the Zed/Nuendo grinding away. I changed the buffer size (made it a notch smaller), and that seemed to kick-start it into correct operation for a while before it started grinding away again. This is the sort of behavior I've read about with Onyx Firewire stuff here, I think. This might be an off-the-wall postulate, but it almost sounds like there's no clock synchronization between the Zed and the computer. I thought that was supposed to happen magically through the Firewire connection, but maybe it's not happening and the audio output from the console is getting out of sync with what the Firewire I/O card in the computer is expecting. If the clock rates weren't synchronized, they'd start off close enough, but would gradually drift apart, causing progressively more missed samples. Does anyone really know how this works? |
|
#24
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
|
|
#25
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
Mike
and how did you deal with the pin 3 dilemma?? I mean the differences between the AES and the EBU until an agreement was reached? (does any standard really get followed if the manufacturer finds a REASON not to?) I think your first post as I found it was about using firewire to create a LAN between some Roland device or was it a Korg ... in one room and your studio setup elsewhere. If someone with your depth of experience can not get a satisfactory setup, what does a layman expect when using these devices. Have you explored finding a local mac user to help test the firewire. ps the mini still has a firewire port. |
|
#26
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
Mike Rivers wrote:
The whole idea behind a computer-based SYSTEM is that things work together because every interface is designed to meet the standards for that interface. Now I recognize that standards evolve and the documentation and universal acceptance often comes along later, and this may be the case here. But "You need a Macbook Pro" doesn't guarantee that it won't be obsolete for the DICE-III or whatever comes along next. Agreed. It seems to me that either the "standard" has some unfortunate wiggle room, or that manufuacturers are claiming to meet the standard but not doing so. Even with Macs, when wanting to expand my FW interface capabilities in order to hang the MIO and the outboard HD on different ports, the TiBook having but one, I was directed to make sure the PCMCIA card I bought used the TI chip. I do that and things have perfectly. But there were plenty of warning of other chipsets not working well or at all with the same computers. -- ha shut up and play your guitar |
|
#27
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
wrote:
why does the apple product work ... good design with a build that is not looking for the cheapest price point. It doesn't take much time to scan the 'net for info on Macs ****ting around some FW situation. And I use Macs erxclusively, with generally fine results and little downtime. Mike said you're not helping. He's right. How about you go get a ZED and hook it to yoru Mac and report back? -- ha shut up and play your guitar |
|
#28
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
|
|
#29
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 10, 3:23 pm, (hank alrich) wrote:
wrote: why does the apple product work ... good design with a build that is not looking for the cheapest price point. It doesn't take much time to scan the 'net for info on Macs ****ting around some FW situation. And I use Macs erxclusively, with generally fine results and little downtime. Mike said you're not helping. He's right. How about you go get a ZED and hook it to yoru Mac and report back? -- ha shut up and play your guitar and what type of wood were you splitting? oak/black locust/ shag bark hickory with a maul or did you get some mechanical advantage? after how many years of hearing the same thing does one have the right to claim that crying wolf is not professional? do you think I could get paid to do it? do you think he will send it to me to try (grin) should I use the ti powerbook or the mac book pro (or the inspiron or the xps)? I just was doing a gut response to his _constant_ plea for firewire help!!! Would you use SAE tools on a metric machine?? |
|
#30
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
wrote:
On Nov 10, 3:23 pm, (hank alrich) wrote: wrote: why does the apple product work ... good design with a build that is not looking for the cheapest price point. It doesn't take much time to scan the 'net for info on Macs ****ting around some FW situation. And I use Macs erxclusively, with generally fine results and little downtime. Mike said you're not helping. He's right. How about you go get a ZED and hook it to yoru Mac and report back? and what type of wood were you splitting? oak/black locust/ shag bark hickory Ponderosa Pine, Douglas Fir, and Incense Cedar. Later I will split some California Black Oak, some Alder, and some Post Oak. with a maul or did you get some mechanical advantage? About three-quarters of it with a maul, and the rest with my father-in-law's splitter. after how many years of hearing the same thing does one have the right to claim that crying wolf is not professional? Every situation is unique. Tell me: does the ZED work with _your_ Mac? Yes or no? If you haven't tried it then assuming it will work with a Mac may not turn out to be valid. do you think I could get paid to do it? Do you have a decade or so of published reviews that support your reputation as a reviewer? Do you have a publisher seeking a review from you? do you think he will send it to me to try (grin) Probably not. He did send me the FW option card for the Mackie Onyx line, because I had one here at the time and we wanted to know how it sounded, if it worked with my Mac, and with Logic Pro 6.4.3. Conversion quality was average, far below that of my MIO, and it worked fine with the computer and app. It also worked fine with the Cube. should I use the ti powerbook or the mac book pro (or the inspiron or the xps)? You should try them all and report back. g I just was doing a gut response to his _constant_ plea for firewire help!!! In general, Mike, when looking for help, gives pretty detailed information about what he's trying to do with what, and about what is or is not happening. The point to take home here is this: he is troubleshooting a specific system and it is pointless to say, "Oh, just change the system". Imagine the moon shots if NASA had taken that approach. "Yeah, guys, well it's not working, so we're going to abandon y'all and try another approach. Any last words for the folks back home? Have a nice death!" Would you use SAE tools on a metric machine?? Not relevant. Firewire is supposed to be a standard at least as tight as either of those, and apparently, as itereated by various manufacturers, it is not. Hence, the pointer to get a card with a TI chip for my Mac when I needed a PCMCIA FW card. Some folks had to return card with other chips and get one with the TI in order to have FW work with their Macs via a PCMCIA card. -- ha shut up and play your guitar |
|
#31
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Mon, 10 Nov 2008 21:02:18 +0000, Mike Rivers wrote:
snip However, here's one for you. I've been working this Zed with files imported from other recorders and getting the progressively worse crackles and dropouts. I didn't want to start recording with it until I knew it worked. Well, this afternoon, I connected my Mackie HDR (analog outputs) to the mixer inputs, put Nuendo into record, and copied an 8-track project to the computer. It played back flawlessly, and has been looping for an hour or so. I opened up Sound Forge and played one of the stereo files that previously crackled and groaned and it, too, played back just fine. It's been going about 15 minutes now without a snort. Now, I didn't DO anything other than to open Nuendo for recording. Surely that couldn't have fixed it. And if it did, how would Nuendo fix it for Sound Forge? I can't retrace my footsteps because there aren't any footprints. I hate it when you don't know why you apparently fixed something, because it's probably still broken. Of course it will work today. November the 10th is the Scottish Pagan festival of Nincnevin, honouring the goddess Diana, who had a daughter by Lucifer. She tricked him by appearing in the form of a cat and seducing him. The celebration of the God who tricked Lucifer (latin: 'Carrier of fire') means this is a most auspicious time for these interfaces. |
|
#32
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
philicorda wrote:
Of course it will work today. November the 10th is the Scottish Pagan festival of Nincnevin, honouring the goddess Diana, who had a daughter by Lucifer. She tricked him by appearing in the form of a cat and seducing him. By the time I tried it here, it would have been very close to tomorrow in Scotland, but that's probably as good a reason as any for it mysteriously starting to work. I suppose if I tried it with a Macbook Pro and it worked, after that it would work with my Dell with the CompUSA Firewire card. The celebration of the God who tricked Lucifer (latin: 'Carrier of fire') means this is a most auspicious time for these interfaces. -- If you e-mail me and it bounces, use your secret decoder ring and reach me he double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers ) |
|
#33
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 10, 4:53 pm, (hank alrich) wrote:
wrote: On Nov 10, 3:23 pm, (hank alrich) wrote: wrote: why does the apple product work ... good design with a build that is not looking for the cheapest price point. It doesn't take much time to scan the 'net for info on Macs ****ting around some FW situation. And I use Macs erxclusively, with generally fine results and little downtime. Mike said you're not helping. He's right. How about you go get a ZED and hook it to yoru Mac and report back? and what type of wood were you splitting? oak/black locust/ shag bark hickory Ponderosa Pine, Douglas Fir, and Incense Cedar. Later I will split some California Black Oak, some Alder, and some Post Oak. with a maul or did you get some mechanical advantage? About three-quarters of it with a maul, and the rest with my father-in-law's splitter. after how many years of hearing the same thing does one have the right to claim that crying wolf is not professional? Every situation is unique. Tell me: does the ZED work with _your_ Mac? Yes or no? If you haven't tried it then assuming it will work with a Mac may not turn out to be valid. do you think I could get paid to do it? Do you have a decade or so of published reviews that support your reputation as a reviewer? Do you have a publisher seeking a review from you? do you think he will send it to me to try (grin) Probably not. He did send me the FW option card for the Mackie Onyx line, because I had one here at the time and we wanted to know how it sounded, if it worked with my Mac, and with Logic Pro 6.4.3. Conversion quality was average, far below that of my MIO, and it worked fine with the computer and app. It also worked fine with the Cube. so all his problems were with his windows setup? should I use the ti powerbook or the mac book pro (or the inspiron or the xps)? You should try them all and report back. g I just was doing a gut response to his _constant_ plea for firewire help!!! In general, Mike, when looking for help, gives pretty detailed information about what he's trying to do with what, and about what is or is not happening. what is not happening is his computer setup it is flawed!! do you want to go into outer space using a flawed low bid system The point to take home here is this: he is troubleshooting a specific system and it is pointless to say, "Oh, just change the system". Imagine the moon shots if NASA had taken that approach. "Yeah, guys, well it's not working, so we're going to abandon y'all and try another approach. Any last words for the folks back home? Have a nice death!" yeah but then they would have a working system before lift off it seems like mike's is never really working! so the scenario would be this we saved $$$$ on a different part does anyone know why it crashed? Would you use SAE tools on a metric machine?? Not relevant. Firewire is supposed to be a standard at least as tight as either of those, and apparently, as itereated by various manufacturers, it is not. Hence, the pointer to get a card with a TI chip for my Mac when I needed a PCMCIA FW card. Some folks had to return card with other chips and get one with the TI in order to have FW work with their Macs via a PCMCIA card. not relevant ... so using any old tool (no mater what the spec is) should work 9/16 is 11 mm about ... why did the bolt strip I bought the lest expensive firewire card ... didn't work tried the next card ... same thing ... after four cards I have one that works ... kinda. some of the time ... when the moon is right. -- ha shut up and play your guitar I was a trombone player now I play the loudspeaker (electro acoustic musician) |
|
#34
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
|
|
#35
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 11, 7:29 am, Mike Rivers wrote:
If that's the case, how come it works now? My problem isn't that I have a flawed system, my problem is that I don't understand what's happening under the hood and I STILL (after years of asking) haven't found out how to figure that out. I can tell you how to troubleshoot what appears to be a cable problem (or determine absolutely that it isn't) using inexpensive, easy-to-use, and easily obtainable tools. Can you tell me how to troubelshoot a Firewire connection problem other than to get another computer? You keep avoiding my real question - which I've certainly stated enough ways so that you surely know what it is that I don't know. Are you suggesting that computers are just too complicated for mere mortals and they only way to troubleshoot the problem is to start over from scratch? I bought the lest expensive firewire card ... didn't work tried the next card ... same thing ... after four cards I have one that works ... kinda. some of the time ... when the moon is right. Given no valid technical means for making a choice, one must start somewhere. Why not start off with the one with the lowest cost? I was a trombone player now I play the loudspeaker (electro acoustic musician) Clearly, then, you have no real world experience with the many varieties of studio equipment. Shut up and play your MP3 files. mike hey great come back I do not own an mp3 or anything that has lossy compression, they suck!!! I do not have your real world experience with the many varieties of studio equipment. I do not write on subjects I have no knowledge. I did give you my answer, http://www.1394ta.org/index.html this was posted here three years ago when you were writing an article on firewire!!! buy something based on research!! if you do not understand something, find an expert! why haven't you posted these problems on the other list-serves I have seen you on? ie http://www.pgm.com/pipermail/proaudio/ http://recforums.prosoundweb.com/ or some place new gearslutz or maybe your public library!! |
|
#36
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 11, 7:29 am, Mike Rivers wrote:
I was a trombone player now I play the loudspeaker (electro acoustic musician) Clearly, then, you have no real world experience with the many varieties of studio equipment. Shut up and play your MP3 files. ah now I get it you have a thing against trombone players... as an electro acoustic musician, I need to explain to you that the original recording studios were for broadcasting so the original engineers were broadcast engineers. when classically trained musicians gained access to these tools they experimented with the electronics. They played sounds created by electronics (the recusers to synthesis) through the transducers that changed electrical energy onto acoustical energy. You know this as a speaker. So they played the loudspeaker, which is the last musical instrument. So all studio engineers who are musicians and are concerned with the "sound" they are creating are electro acoustic musicians. Even classically trained trombone players. or self taught bluegrass pickers!!! |
|
#38
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
|
|
#39
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
On Nov 11, 12:30 pm, Mike Rivers wrote:
Actually, I played the trombone when I was in 7th through 9th grade. Sold it to buy a guitar when I got into college during the Folk Scare. Turns out that a lot of folk musicians from the late '50s and '60s were trombone players in another life. I actually wanted to be the next Paul Desmond, but the school didn't have any alto saxes but they needed trombone players for the band. I kind of liked JJ Johnson and Kai Winding's duets at the time, so I said "OK, I'll learn to play the trombone." mike my writing ability is always correct, opps sorry for misattribution true blue trombonium - jj & kia on dave brubeck live at the 57 newport lp. may I suggest you post on a computer savvy group. my logic is that although your topic is audio, your subject problem is computer. and maybe someone more computer literate may be able to better direct you to someone or place that will further your quest. |
|
#40
Posted to rec.audio.pro
|
|||
|
|||
|
DICE II Firewire Driver Settings
wrote:
On Nov 11, 12:30 pm, Mike Rivers wrote: Actually, I played the trombone when I was in 7th through 9th grade. Sold it to buy a guitar when I got into college during the Folk Scare. Turns out that a lot of folk musicians from the late '50s and '60s were trombone players in another life. I actually wanted to be the next Paul Desmond, but the school didn't have any alto saxes but they needed trombone players for the band. I kind of liked JJ Johnson and Kai Winding's duets at the time, so I said "OK, I'll learn to play the trombone." mike my writing ability is always correct, opps sorry for misattribution true blue trombonium - jj & kia on dave brubeck live at the 57 newport lp. may I suggest you post on a computer savvy group. my logic is that although your topic is audio, your subject problem is computer. and maybe someone more computer literate may be able to better direct you to someone or place that will further your quest. Now _that's_ the spirit! g -- ha shut up and play your guitar |
| Reply |
|
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Forum | |||
| M-Audio FireWire Audiophile driver (1.7) problem | Pro Audio | |||
| FS: Phaze Audio Line Driver model LD-2 Butler Tube driver on Ebay | Car Audio | |||
| FS: Phaze Audio Line Driver model LD-2 Butler Tube driver on Ebay | Marketplace | |||
| Driver Design - What makes a good driver | Tech | |||
Linear Mode
