On Wed, 2010-06-30 at 06:34 +0200, Ichthyostega wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ralf Mardorf schrieb: > > For my understanding I wish to compare some knowledge from the C64 with a > > modern Intel/AMD Linux PC. I don't have much knowledge about the C64 > > anymore, > > but some notes at hand. > > > > Is there a difference for Intel/AMD Linux PCs for IRQs and NMIs? In other > > words, for the C64's 6502 CPU there were two commands, SEI and CLI. > > > > The SEI command did disable IRQs. IIRC IRQs were interrupts for all > > hardware > > and programs, excepted if a program called the SEI command. IIRC just the > > restore and reset buttons did cause a NMI, an interrupt that can't be > > disabled, but that isn't done by an interval automatically. > > > > So, if you did real time MIDI programming you call SEI to disable all > > interrupts, so that just the currently needed MIDI route was allowed to > > run, > > there were no IRQs anymore. > > > > For example you directly asked the UART connected to the bus if there was a > > byte > ... > > Hi Ralf, > > above you give a very concise summary of what was the proper way of > programming in the days of the C64 :) > > Now you ask about differences to today's CPUs / Systems. > > * Most important, modern CPUs are always operated in the so called > "protected mode". Whereas the 6502 had only what is known today > as "real mode". In real mode you operate directly on the hardware.
Yes, I noticed the difference, when I had a look to Data Becker PC Intern 2.0 from 1990 ;) this morning. It seems to be that when I did program for my 80286 hardware emulator on the Atari ST at least the BIOS was between my program and the hardware. > Protected mode means, that there are "processes" which get an virtual > address space. When the program in this protected space tries to access > any other memory location, the hardware of the processor triggers a so > called "protection violation" and the running program is immediately killed. > > The memory addresses the program "sees" aren't the real ones, rather they > get translated on-the-fly. Under the usual circumstances, the addresses > corresponding to hardware components in your PC are never exposed to > normal programs. > > * Next, a fundamental difference with modern systems is the "pre-emptive > multitasking": Several processes are "runnable" at at the same time, > and when any given process gets a "time slice" to run, it can execute > some instructions; but when the time slice is over, the process will > be interrupted and frozen without any further notice. This can happen > between any two assembly instructions and the program has no way to > find out about that, to avoid it or even to prepare for it. This also > explains why it's impossible for a normal program to do anything with > IRQs: if this would be allowed, any process pre-empted while just in > the middle of handling an IRQ would inevitably deadlock the whole > system. Ok, anyway, MIDI within Linux is without jitter, so real multitasking seems not to be an issue. Anyway, I wonder about real multitasking, even a C64 is able to do faked multitasking (limited to the 1MHz) and then IRQs anyway could be controlled. > * Another important difference is memory mapping and DMA. For one, memory > pages might be mapped to blocks in a file on the mass storage (and actually > be swapped in and out as required). This works and is made possible by DMA. > Not only the CPU, but several peripheral components can transfer blocks to > and from the main memory. Most any communication and data exchange with the > hardware relies on this mechanism. > > * Besides, we should note that the CPUs got way faster, even faster than the > main memory. Please note that! a modern CPU is too fast for the normal RAM > to cope with. To add to this poisonous mix, we get more and more CPU cores > working at the same time. Normally, there is no guarantee that one core > even sees the effect of operations the other core does at the same time. Ok, there must be an instance that does sync different fast hardware components to the main bus. > I think, the above list is enough to show you that the classical assembly > programming technique is completely useless on a modern system. It doesn't > bring you anywhere, if you try to do things as we did on the C64. Its > impossible to get the described situation "under control" in such an > environment. We would have to switch off pretty much everything which > defines a modern PC > > > Instead of polling hardware registers or writing our code in IRQ handlers, > we use two quite different basic programming techniques today, when we want > to "talk to the hardware": > > (1) blocking I/O: when you read/write to an object which appears to live in > the file system, actually you're invoking a OS kernel function. Right > in this function, your process or thread gets interrupted and frozen, > while the Kernel schedules the necessary operations actually to make > your read/write happen. Millions and millions of cycles later, when > the hardware has placed the result by DMA into the memory, the Kernel > awakens your thread, prepares the required values by reading from > this DMAed memory blocks, and finally returns from the system function. > Your program gets the impression just to have done a simple subroutine > call. > (2) Callbacks. This is often the preferred variant when it comes to high > performance, and asynchronous communication. For this, you register > a callback function with some library, which actually forwards/involves > the Kernel in some way. Now, when the actual event / or result is due, > e.g. the hardware has placed results by DMA into the main memory, the > Kernel then maps this memory block into your processe's address space > and than invokes your callback routine and passes the virtual address > of the data. > > > > Jitter seems to be caused at the latest handoff. > > > IMO it should be avoided to keep in contact to the UART by any software > > interface, this must be done directly. > > Ralf, what makes you so sure about that conclusion? > > Actually, we don't even know if the UART is to be handled and read by > the CPU. It is very likely that the UART connected to the external MIDI > bus is actually run by an autonomous device, which talks to the core > system via an other intermediary protocol, like USB. And USB seemingly is an issue, further to Niels. > What you want is to get an reproducible reaction on an MIDI event with > an time error in the range of a few milliseconds, instead of some 10 ms > Today's CPUs have clock cycles in the range of GHz. This is a thousand > times faster than the C64. The single operations today run in the range > of nanoseconds. The CPU can do about one million instructions while sound > travels 30cm. > > > Im jobless and thinking about to get knowledge about Linux rt, the kernel > > and > > C, C++, OTOH I'm thinking about to care less about Linux audio/MIDI and > > get > > a job instead ;). > > > The problem is that "Linux" and "PC hardware" can't be learned in one week. > > There isn't a book like the Data Becker "C64 Intern" and Data Becker > > "COMMODORE 64 & 128 - Maschinensprache für Einsteiger" that enabled this and > > that enables gifted people to get absolute control for any C64 kernel, and > > the complete hardware in 3 month. > > Very true. The whole situation is way more messy. And the problem you're > pointing at (MIDI jitter) is in itself a challenging and difficult to tackle > problem, and moreover a problem which some people aren't even able to perceive > > > If there are unavoidable issues for Linux and/or the PC hardware, than it's > > useless to think about Linux and/or PCs for music. Obviously the PC hardware > > seems to work better for Windows and MacOS regarding to music. > > Not only regarding to music. This is a concern for pretty much every > more hardware related thing. Printers, scanners, screen colour correction, > interfacing to video cameras,.... endless list > > Commercial interest causes things to become smooth for Windows and MacOS. > For Linux we're in the unfortunate situation that we need to come along > with the scarce resources we have and with what just happens to work. > Indeed the industry constantly pushes out new hardware/software solutions, > an we're only able to keep up with that pace by virtue of all this indirection > and software layers in between. So that is the fundamental problem you're > referring to. > > But still, if you ask me -- my intuition tells me that we're not facing > an unsolvable problem with PC hardware and systems. The systems should be fast > enough, and the basic design of the OS is clean enough to get much more > complex > things to work. We should try to take a step back. Actually, we agree that > there > is some problem with jitter, but we still have no clear model of the > situation! > > Is something broken (bug or regression)? Is some hardware involved which is > unreliable or just not performing well enough? Is there a design flaw in the > ALSA MIDI interface? Was ALSA MIDI and/or jack MIDI in itself designed to be > precise enough? > > > I think it would help first to describe the situation in a more distant > fashion, > without going into technical low level details immediately. > > First of, we *do* need a clear model of the situation. How are the components > connected? Which is exactly your situation were you observe the jitter? And > are > there situations which are *not* affected? (Soft seq driving soft synth?) No jitter when using soft synth. Super-jitter when using USB MIDI. > What are you doing? > Playing a soft sequencer to external hardware MIDI? I wish to use a soft sequencer to play external hardware only + doing hard disk recording on the same machine. > Or to external and internal > instruments at the same time? Playing on a MIDI keyboard and routing the > MIDI events to external hardware and a linux based soft synth at the same > time? Playing a MIDI keyboard and routing to external only would be needed, but it wouldn't be bad to use soft synth at the same time too. > - From the previous discussions I take it that an USB MIDI device is involved > somehow. (We know, USB, as pretty much everything on PC systems, is designed > for throughput, not for quick reaction and low latency). If USB is involved, > we indeed need to find out in which part of the chain the jitter arises. > It might be USB alone. It might be that ALSA MIDI also has a problem. It > might be that the combination of both doesn't play well. Is the Jack server > involved too? I am quite aware that finding that out with simple means is > by far not a simple task. But it could help to narrow down the root of the > problem, so that it's possible to determine if there are chances to > address and solve it. > > Cheers! > > Hermann Because of a broken hard disk, a final account by the power company etc. I can't pay even 0,99€ this month for a PCI sound card with a gameport MIDI. IMO the next test should be to replace USB MIDI by PCI MIDI. Theoretically I do have a gameport MIDI, in reply to Niels on LAD: -------- Forwarded Message -------- From: Ralf Mardorf <[email protected]> To: Niels Mayer <[email protected]> Cc: Linux Audio Developers <[email protected]> Subject: Re: [LAD] [64studio-users] MIDI jitter Date: Wed, 30 Jun 2010 06:34:55 +0200 On Tue, 2010-06-29 at 18:20 -0700, Niels Mayer wrote: > TTL level MIDI in and out Assumed it's not broken, than for my Terratec EWX 24/96 there's an issue for the pin allocation. Do the ports for most sound cards usually have the common pin allocation? My ASUS M2A-VM HDMI has got 1 x PCI Express x16 formerly used for HDMI, now for a GeForce 7200 GS 1 x PCI Express x1 slot unused 2 x PCI one unused, the other for the Terratec EWX 24/96 Mounting an additional sound card won't cause an issue because of an additional interrupt? There will be no issues, e.g. for JACK, if I would use the Terratec EWX 24/96 for audio and another sound card for MIDI? So USB MIDInterfaces are for bulk dump only ;)? :) Ralf _______________________________________________ 64studio-users mailing list [email protected] http://lists.64studio.com/mailman/listinfo/64studio-users
