On Wednesday 05 March 2003 01:16, Roger Williams wrote: What could I do if I can't set irq's in my bios? -- Jaakko Prättälä Jaakko.Prattala(a)Helsinki.FI

On Sun, 2003-03-23 at 01:59, Jaakko Prättälä wrote: Jaakko, Hi. First, what machine are you running and what BIOS does the machine have? Phoenix? Award? Usually you can set IRQ's, but often the settings are hard to find. In my machine it's under Advanced->PCI Configuration. Even though I have this feature, I still recommend that you should: 1) Remove all of your cards EXCEPT graphics, boot and look at interrupt settings. Write them down or save a file somewhere. 2) If you have on-board devices, like sound or LAN, then you should attempt (through BIOS if available) to put them on low-priority interrupts. (3,4,5,6,7) 3) Add a card, such as your HDSP that drives the multi-face, on maybe PCI slot 3, boot the machine, and look at what interrupt each device is on. If you get 9 or 10 for the HDSP, then you're in pretty good shape. If you do not, then again, set the PCI slot to IRQ 9 if available, or try a different slot with just the HDSP and no other cards. (Always graphics installed, obviously!) 4) Go through this process, adding a single card, booting, and looking at which IRQ each card has, until you get your important sound card/s on the best IRQs. Again, IRQ order is: 0,1,8,9,10,11,12,13,14,15,3,4,5,6,7 2 does not exist. (Or it's called 'cascade'.) 0,1 & 8 are not available. 9 is best, followed by 10, etc. 10 is as good as 9 if 9 is not used, or only used by acpi support. Networking works fine on 3-7. I hope this helps. Feel free to write directly if you have other questions. Cheers, Mark 3) NOTE: On my machine, BIOS seems to move the USB interrupts around as I chan

Ron, OK, most import item - if it works, then have a beer and make some music! There is no reason to get overly concerned about this stuff if the machine does it's job. I think your machine is using the newer 'APIC' and 'IO-APIC' type interrupt controllers. I actually got brave and joined the kernel developer's reflector to ask some questions about this as I was not sure (and am still not) about IRQ priorities in this hardware configuration. To be clear, this is hardware that is part of a newer PC architecture and is NOT the same as most machines out there in the world. (I.e. - it's been around for a year now, but it's new, and likely to work well for most PC uses, but less sure about audio applications.) Don't get worried, as I know a number of people using it on Pro Tools and doing fine, although many of them had problems getting it to work well in the beginning. Also, I do not have a machine with this hardware to do any testing on, so I cannot be sure about any of this. We'll just have to figure it out. My rudimentary understanding of this configuration is that the hardware priority is lowest to highest, except for the normal, out-of-order issue about IRQs 3-7. Since those are apparently not assigned on your box, I hope they don't matter. This would imply, in your case, that one or your SCSI controllers trumps your RME, and both trump the ICE1712, which I presume is an on-board sound chip. (16 is before 17 is before 18 is before 19) I do not 'think' that this will be a big problem as SCSI controllers are normally pretty well designed and have good buffering. I'm a bit more concerned about the mouse at IRQ 12 trumping all of them. This _has_ been a problem on the normal IRQ setup and _could_ be a problem for you. (I'm just guessing.) To test this, I'd suggest starting jack using the RME with a buffer size of 64 and verbose logging, but no recording. I'd then try moving the mouse around violently. Lots of mouse movement will cause lots of mouse interrupts, and you'll get an idea how the system is handling all this interactive load. If that works, then I'd do the same thing with Ardour doing playback, but not recording, and see how mouse movements effect it, and then finally the same while doing recording and playback. Also, remember that as PC's get fast and faster, and if the interrupt handler's are written better and better, then it could get to the point that IRQ order no longer makes a difference. I don't think we're there yet, but I do think we're getting closer. Drop me a note if you need some more specific info. Cheers, Mark On Sun, 2003-03-23 at 07:00, R Parker wrote:

Jesse, I am not recommending this course of action, but really just passing along info from the dark side. Windows NT/2000/XP uses a layer called the HAL (Hardware Abstraction Layer) which determines how Windows is going to configure hardware. (Basically the motherboard chip set and AGP only I think) When you do the install of Windows, and 'undocumented' feature in the paperwork M$ delivers, but it is available on the web, is that you can choose the HAL layer you want. One HAL layer does this new IRQ munging, while another allows you to configure the MB usign the traditional method of doing interrupts. If Linux does something similar, and gives you a choice, then it would be interesting to boot one of these machines with the old style HAL layer. The negative on this idea is that I am not at all sure that you are allowed to do this, even in Windows, for an SMP machine. It may only be allowed on UMP boxes, as there are good technical reasons for wantign to use the IO-APIC model with SMP. Anyway, just info. You probably knew all of that already. Cheers, Mark On Sun, 2003-03-23 at 09:51, Jesse Chappell wrote:

Hi, --- Jesse Chappell <jesse(a)essej.net> wrote: jackd -v -d alsa -d hw:0 -p 128 I add "-R" towards the end. creating alsa driver ... hw:0|1024|2|48000|swmon|rt dd if=/dev/zero of=/home/studio/clients/tmp/bigfile bs=1000 count=1000000 No Xruns Changed buffer to 256 and left bigfile to be overwritten. Does that mean a 'rm bigfile' happens? **** alsa_pcm: xrun of at least 3.964 msecs Changed buffer to 128 left bigfile to be overwritten **** alsa_pcm: xrun of at least 11.129 msecs ran 'jackd -R -v -d alsa -d hw:0 -p 128' buffer 128 and rm bigfile, I gave it a few seconds before changing xterm windows. No xrun Repeat last test with buffer 64 and no xrun Repeat last test but didn't 'rm bigfile' no xrun Interesting, I'd gapped and forgot to use "-R" when I was experiencing xruns. Including "-R" seems to be improving performance. jackd -R -v -d alsa -d hw:0 -p 64 Have changed the location of bigfile to the same drive where the OS is installed. Previous tests are to a scsi LVD 160, raid5, seven drive array of cheetah 15,000rpm, 3.3ms seek, 18 gig drives. No xruns, it took longer to write bigfile With "-R" I'm going to test recording eight tracks of audio into Ardour. I'll report those results soon. The conclusion thus far, for me, is to pull head out of arse and use the "-R" flag. ron __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com

R Parker wrote on Mon, 24-Mar-2003: And you have said that you have no need to use such low-latency, so you should be totally fine with a bigger buffer size (probably). It is looking good for you. jlc

Hi, In the same spirit of your realization, I'm designing a runlevel for my gentoo audio box. I use this machine in the studio as an atalk/netatalk fileserver amongst other things. So far, I'm shutting off all networking, usb, cron and printing services in the new audio-print runlevel. I saw in Jan Depner's documentation where he shuts off services and turns on lowlatency using a script. Jan's docs are another informative read. I don't have a link available, sorry. ron __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com