Hi Derek derek holzer <derek(a)x-i.net> writes: I do know these fine links and have consulted them before asking here. Unfortunately they cover only the non-APIC interrupts. So I try it again: How do I best set up my sound card regarding interrupts on a contemporary motherboard? (ASUS P4P800) Does APIC make the situation better or worse? Should I try to switch it off? Please advice, Robert Epprecht

Hi, I asked some questions about this of the Linux kernel developers in September of 2002. I received a couple of pretty informative answers. I found them online for you and have attached the links below. At the outset I'll admit that this information is not enough to really answer your questions, but it will hopefully serve to point you in the right direction. By way of background, I designed chipsets and I/O devices for AMD in the early 90's when the PC was getting more standardized, so I have a good grounding in the original IBM architecture, but I've been on 1394 since the APIC advances have happened and hove zero experience in this area. Take this with a grain of salt. My original question: http://www.ussg.iu.edu/hypermail/linux/kernel/0209.3/0133.html The two responses I received: http://www.ussg.iu.edu/hypermail/linux/kernel/0209.2/0234.html http://www.ussg.iu.edu/hypermail/linux/kernel/0209.3/0189.html You'll need to puzzle out what this two responses really mean. The kernel guys can be a bit terse. (Not in a negative way. They just give answers they understand and that the rest of us probably need to dwell on for a few years before we see the light.) The problems I had with these explanations was that they didn't clarify the routing of physical interrupt lines to the order of the vector tables. In motherboard design, the layout of the interrupt lines may possibly be a single line between two or more devices. For instance, the physical interrupt line for an AGP graphics controller is often the same physical line routed to the upper most PCI slot. Since they share the same physical line they have to be shared, but this discussion didn't clear up for me how that's done. The devices go into their own vector even if they are shared. (AFAICT) Also, the first link says 'For APICs, when two interrupts are present when interrupts are enabled, the one with the highest interrupt vector number will be taken first' and 'So, the last PCI interrupt source in the MPS table will be the highest priority'. However the second link says 'The local APIC unit will handle interrupts depending on vector, with lowest being highest priority. Here is a sample table with NR being the IRQ e.g. 0 = 31;' For me this wording seems contradictory, but I think I was confusing the interrupt number with the vector number somehow. I didn't have an SMP machine to look at this with, and while one of my machines does have an APICIO controller I don't use it and haven't been driven to try. (Sad - this is over a year ago!) ;-) I am quite sure, however, that to make a PC work well the PC chipset must be given the highest priority when servicing interrupts since it contains the RTC and other things that must be serviced very quickly, while PCI cards can be serviced (in general - not sound) when ever the PC gets around to doing it. One other piece of interesting information was that you can supposedly control the ordering of the interrupt table using some kernel type software. This would be quite cool since you could then insert your sound card anywhere into the list and give it the very best servicing that your machine can provide. Good luck figuring this out. I'd like to understand it better myself, so don't hesitate to pop back with some questions. Cheers, Mark

Clemens Ladisch <clemens(a)ladisch.de> writes: I'd like to know more about that, Robert

Hello list members! I'm new to this list and relatively new to Linux. I discovered the power of Linux about 2 years ago and began switching my school district over to it (still migrating). I use only Linux for my servers (web/email/proxy/file/backup/etc.). I've setup two classroom labs using Linux as the desktop. I'd like to look at using Linux in the music lab (not yet created). So I found this mailing list. I'm a keyboardist and MIDI user (since Cakewalk first came out). I want to create a DAW (for my home use as well as for school). I need it to do MIDI and samples and record audio. I'm trying to get a Delta 66 with Omni breakout box for the soundcard, and maybe a Soundblaster Live (w EMU10K chip) for the soundfonts. My questions to the list... 1) Are there Linux equivalents to Reason, Sonar, FruityLoops, Cubase, ProTools, etc.? Really? 2) Is anyone using dual processors (maybe PIII 500 Mhz) successfully? -- =========================================================== Richard K. Ingalls Director of Information Technology Glenwood R-8 School District West Plains, MO email..ringalls(a)glenwood.k12.mo.us web....glenwood.k12.mo.us ph.....417.256.4849 fax....417.257.2567 "Glenwood R-8: home of the mustangs!" ===========================================================

On Tue, Jan 20, 2004 at 11:36:28AM -0600, Richard K. Ingalls wrote: By "equivalent" I assume you mean "an application X on linux that has integrated all the major features of application Y on windows." For various historical, cultural, and practical reasons, this tends not to be the way that linux audio developers work. not in one app. for equivalent functionality: You could build your own with PD! Or you can run hydrogen, seq24, jack-rack, and any number of soft synths at the same time. It's fun - except for restoring sessions later which you have to do largely by hand or with shell scripts, a major pain in the butt. This is an issue that will hopefully improve as more developers adopt LADCCA. not in one app. ardour + rosegarden4 / muse / seq24 + jack rack + various soft synths. Same session management problem as above. no. maybe. try Muse and Rosegarden4. You should really check out the latest Ardour beta. not me, but several of us are. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's IAMBIC CLOWN ALPHA! (random hero from isometric.spaceninja.com)

Yesterday, I wrote: I've looked into the Intel documentation, and it turns out I thought wrong, i.e., the first quoted link is right. (But it was for an older Linux version which assigned vector numbers consecutively.) Section 8.3.3 of the "IA-32 Intel(R) Architecture Software Developer's Manual, Volume 3: System Programming Guide" says: | For interrupts that are delivered to the processor through the local | APIC, each interrupt has an implied priority based on its vector | number. The local APIC uses this priority to determine when to | service the interrupt relative to the other activities of the | processor, including the servicing of other interrupts. | | For interrupts vectors in the range of 16 to 255, the interrupt | priority is determined using the following relationship: | | priority = vector / 16 | | Here the quotient is rounded down to the nearest integer value to | determine the priority, with 1 being the lowest priority and 15 is | the highest. Because vectors 0 through 31 are reserved for | dedicated uses by the IA-32 architecture, the priorities of user | defined interrupts range from 2 to 15. | | Each interrupt priority level (sometimes interpreted by software as | an interrupt priority class) encompasses 16 vectors. Prioritizing | interrupts within a priority level is determined by the vector | number. The higher the vector number, the higher the priority | within that priority level. In determining the priority of a vector | and ranking of vectors within a priority group, the vector number is | often divided into two parts, with the high 4 bits of the vector | indicating its priority and the low 4 bit indicating its ranking | within the priority group. So, if Intel's explanation is correct, higher vector numbers have higer priority. For example, on my P4P800, dmesg says: .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 003 03 0 0 0 0 0 1 1 39 02 003 03 0 0 0 0 0 1 1 31 03 003 03 0 0 0 0 0 1 1 41 04 003 03 0 0 0 0 0 1 1 49 05 003 03 0 0 0 0 0 1 1 51 06 003 03 0 0 0 0 0 1 1 59 07 003 03 0 0 0 0 0 1 1 61 08 003 03 0 0 0 0 0 1 1 69 09 003 03 0 1 0 0 0 1 1 71 0a 003 03 0 0 0 0 0 1 1 79 0b 003 03 0 0 0 0 0 1 1 81 0c 003 03 0 0 0 0 0 1 1 89 0d 003 03 0 0 0 0 0 1 1 91 0e 003 03 0 0 0 0 0 1 1 99 0f 003 03 0 0 0 0 0 1 1 A1 10 003 03 1 1 0 1 0 1 1 B9 11 003 03 1 1 0 1 0 1 1 B1 12 003 03 1 1 0 1 0 1 1 A9 13 003 03 1 1 0 1 0 1 1 C1 14 003 03 1 1 0 1 0 1 1 D1 15 003 03 1 1 0 1 0 1 1 D9 16 003 03 1 1 0 1 0 1 1 E1 17 003 03 1 1 0 1 0 1 1 C9 So, interrupt 22 (0x16) has the highest priority (vector 0xE1), followed by interrupts 21 and 20, etc. (On the P4P800, these interrupts are assigned to the onboard 3C940 and PCI slots 5 and 4, respectively.) It would be possible to assign a different vector number to a specific interrupt by patching the assign_irq_vector function in arch/i386/kernel/io_apic.c This explanation is slightly wrong, too. The processor priority isn't determined by the TPR but by the PPR (Processor Priority Register), which is computed as follows: | [T]he processor priority is set to either to the highest priority | pending interrupt [...] or to the current task priority, whichever | is higher. The TPR is used to suppress interrupts which have a lower priority than the current task priority. Regards, Clemens

On Wed, Jan 21, 2004 at 03:36:45 -0800, Mark Knecht wrote: I'm out of my depth here, but form what I understand its possible to assign vectors, and a wraparound point in software. - Steve

Clemens, Hi. Thanks for the response. It's very helpful and good information. Since I think there is still some differences between your software and my hardware points of view so I'll continue to ask a few questions and document my points below. No *major* disagreements with what you wrote, maybe one minor one at the very end. Mostly this is still clarification and comparison. - Mark <SNIP> Possibly true, or should be if software is designed right. Speaking as a hardware designer who has worked on chipset and many different I/O controller technologies (SCSI, EIDE, Ethernet, 1394, USB and legacy) I can assure you that this is not always true. None the less, it only takes one delay to create an xrun and blow a live recording. ;-) OK, now it's extremely well known fact that I'm not a programmer. Why would you think there was *any* chance I'd ever written a driver? ;-) (Though I have managed Windows SCSI driver programmers and have some first-person background...) <SNIP> <SNIP> It was not marked as such in my system. 17 was marked 0x00. None the less, it wouldn't change thing much. (0x00 vs. 0x11) Ah! Ok, that's good info although my system sort of makes it look like LOC: and IRQ0: are the same thing since they always have the same number of interrupts. <SNIP> OK, so then the real question is how does APIC mode change the relationship between all of the older 'legacy' devices and the PCI bus. It's not difficult to show, so let's map this out, old style vs. APIC style. I'll show the highest priority interrupts at the top of the list (legacy style) since I expect that someone like Jan Depner might be reading this and possibly someday it would make it onto his pages. I'll add an APIC column for what I think I'm reading in your words and then we'll correct my misunderstanding or your POV. Legacy Function APIC Style IRQ255 ... IRQ16 PCI slots?????? IRQ0 Timer Timer IRQ1 Keyboard Keyboard IRQ2 Cascade->IRQ8-15 Cascade IRQ8 RTC RTC IRQ9 PCI IRQ10 PCI IRQ11 PCI/VGA IRQ12 PS/2 Mouse PS/2 Mouse IRQ13 (Old FPU) IRQ14 IDE0 IDE0 IRQ15 IDE1 IDE1 IRQ3 Com2/PCI Com2 IRQ4 Com1/PCI Com1 IRQ5 Parallel/PCI Parallel IRQ6 Floppy Floppy IRQ7 Printer/PCI Printer Now, my point is that I do not think/believe/agree that the PCI slots are intended to have higher priority than the Timer or the keyboard. I could certainly be wrong, but to me it doesn't make sense. On the other hand, I could certainly agree with the idea that all of the APIC stuff could link in around IRQ9 (like it does on an XP machine) with a second level of priority assigned by the vector in the table. I am just not sure which you are suggesting is true. Notes for casual readers: a) I add PCI to IRQs 3, 4, 5 & 7 from personal experience. Not all motherboards support this. b) I do not show onboard devices that may share interrupts, such as USB, USB 2.0 or 1394. Consult your motherboard manual or 'lspci -v' for more info on your system. Manufacturers are free to rearrange most anything if they don't care about DOS compatibility. c) VGA interrupts are often shared with a PCI slot. On many systems the interrupt number can be reassigned. On many of my legacy systems I run it at IRQ11. <SNIP> I think you wouldn't say this if you placed an active Gigabit Ethernet adapter at interrupt 22 and a sound card at interrupt 21. Maybe that's not practical enough What about a 10/100 Ethernet at 22, a 1394 adapter at 21, maybe a USB controller at 20 and your sound card at 19. Over time my experience is that you will see xruns. Change the order to sound card at 22 and you see fewer xruns. Or that's my experience. With best regards to you too! - Mark