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
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
> * 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
> (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.
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
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@example.com>
To: Niels Mayer <firstname.lastname@example.org>
Cc: Linux Audio Developers <email@example.com>
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
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
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
64studio-users mailing list