On Mon, 2010-06-28 at 06:51 +0200, Ichthyostega wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ralf Mardorf schrieb: > > I'm not able to read source code a, based on the headers b, c, d, e, f, g, > > h, > > i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z. > > > What is the result for the machine code (Assembler ... yes, I'm able to > > disassemble the result of the C code)? > > What assembler? Are you even remotely aware how a modern processor differs > compared to our good old beloved C64? Are you aware that even by changing > some option switches on the compiler, or even by some autodetection like > the "configure" scripts do, the compiler might emit another instruction > set, i.e. code the same behaviour up quite differently? This is madness, > isn't it?
I'm not fully aware about this possibilities. Btw. I'm aware that for the C64 and Atari ST the UARTs are directly connected to the bus, while for my PC at least some protocol for USB seems to be an instance that is between the main bus and the UART. I'm searching for reasons. Ignoring questions about compilers etc. won't change the issues regarding to jitter. > > I've forgotten, the C64 was limited to 64kiB and you even don't need 1kiB > > to > > program a stable sequencer. > > Geez. Today even a "sticky notes applet", you know, that tiny yellow notes > you can put on your desktop... even this small and maybe usefull bit of > desktop convenience, occupies (hold onto your hat) 220MiB of virtual memory. > This is madness, isn't it? > > Ralf, please acknowledge that the way we deal with computers and programming > today has been changed fundamentally. Like it or not, today, that is 25 years > after you and me got our own hands on experience with "real time" programming > in assembler on the good old C64. > > Certainly this wasn't a decision made consciously by one person or a group or > body in charge. But effectively, it is like a decision the programming guild > as a whole has taken: > > - - no one is assumed to read assembler anymore. Assembler isn't "the reality" > - - the instruction sets of the machine language is no longer crafted to be > manageable by humans. It is built for the sole purpose to be generated > by software. > - - processors are even allowed to re-order and rewrite and modify the > assembly > on-the fly within certain limits, which are defined separately for each of > the zillions of different processor families > - - we have given up to have one definitive and reliable platform with > clearly settled specs. Rather, each system is different and just assumed > to be within certain limits, and all of this is managed, buffered, > controlled, > adjusted and translated by layers and layers and layers of software. > - - on a general purpose PC (irrespective if Linux, or Windows or MacOS), no > one > (mind me: no one) is allowed to execute direct control, in the way we did in > former days. The OS/Kernel is always in charge. You don't get direct memory > addresses, you aren't allowed just to "handle an IRQ", unless you're a > virus. A virus must not be something evil. Sciences try to heal cancer by using retroviruses. If possible, dunno if it would be possible, but if so, why not using a good virus to avoid jitter? > - - we have allowed our software to grow to a size way beyond what any human, > even Albert Einstein, could even remotely understand and control in every > detail. Exactly. reading 20kB machine code is hard to do, 20MB machine code is impossible to do. It's ok for some software, but not to fight issues regarding to rt. Btw. it's not a question regarding to the IQ, but to the limit of time to read such amounts of code. > - - the morals is changed. The "good" programmer is able to work with > abbreviated > knowledge and abstractions, while the "tinkerer", the person who turns every > bit and writes arcane, hand optimised code generally is perceived as a risk. > > Note, I am not the person to glorify any of these developments. > > So please, stop stamping like a child and shouting around about what is the > right way to deal with MIDI. What was the right way of handling things in the > 80es, isn't the usual way of handling them today. And please, stop insulting > persons which *are* able to get things done and settled in this different > environment today. Things aren't getting done. For audio more and more people do experience the same as I do. JACK1 disconnects clients and JACK2 often doesn't work, because of async. For MIDI hw devices there's MIDI jitter. Most people solve this by switching to Windows. I keep Linux and I'm asking to reconsider concepts. Maybe in a childish way. > So far for the general, philosophical part. > > I am very much sympathetic with your fight trying to hunt down the problems > with MIDI jitter. As long as people use only soft synths, and basically just > "render" MIDI on a computer, this may seem like an esoteric problem. But it > gets a real problem the moment you'll try to use the computer in a chain > with other hardware or computers and try to play this whole compound live > and in realtime. > > "Realtime" -- we should be careful with this term. What we knew as "realtime > programming" in the good old C64 days, corresponds best to what is known > today as a "hard realtime system". I said "corresponds", because even > when we talk of "hard realtime" today, the meaning is just that there > are certain guarantees by the OS. > > But no general purpose PC operating system gives even remotely such > guarantees. > These systems where built and optimised for throughput, not for quick > response. > All we can achieve, by using somewhat tuned an modified kernel versions, is > to get the so called "soft realtime". That means, when we set up and register > a handler for some kind of event, on *average* we can *assume* the kernel > will dispatch our handler within certain time limits. I would be fine with a fixed latency (latency without jitter). If this shouldn't be possible regarding to hardware issues, than here's another question. Is it possible to use the parallel port, PCI, PCI express as the expansion ports of oldish PCs? Are they directly connected to the main bus? (I will search the web myself too). If so, we could think about making a simple circuit to use the UART this way. > So that is all we get, and we have to cope with it. But considering that the > average PC today is at least 1000 times faster than the C64, we *should* be > able to get down to 1-2ms, even with such a OS. > > But seemingly, we don't; rather we get errors in a range with is easily > perceptible for a musically trained ear. So there needs to be a misconception > hidden somewhere. > > But the problem is, we won't be able to spot it by reverse engineering the > assembly. This is beyond the human capacity. The misconception / or mismatch > happened on a higher, more abstract level, because that is where anyone > doing computer engineering today works. Perhaps it's possible to go back to old concepts. At least there seems to be just 2 sequencers for Linux, ALSA and JACK, while JACK needs to talk to ALSA for the hw access. Nobody really does write an individual MIDI sequencer, they all are just backends. > You know, if the goal is to hunt down and trap a criminal, it is not enough > just to think "morally sane". Rather we need to understand how a criminal > thinks > - -- so we can spot what he overlooked. The same Idea applies here. If the > goal is > to hunt down and nail a bug, misconception or design flaw in a modern computer > system, it doesn't help to claim the "right way". Rather we need to get into > the > style of thinking which was applied when constructing the system. > Without loosing the critical spirit, of course. > > So to give you a starting point: > You have a situation where you can sort-of reproducibly show the jitter. OK. > - - what is the topology? what components are involved and how are they > connected? I started tests, regarding to the connection, unfortunately my PATA drive is broken and I need to wait for the yearly final account for the electricity supply and delivery, before I can continue my experiments. > - - what protocols are involved on what parts, which could be relevant? In my case at least the USB protocol seems to be between the main bus and the UART. > - - what are the guarantees each of these protocols give? > - - when we combine all these guarantees (in a sensible way, according to the > situation): do we get a margin which is lower than what we actually observe? > ++ if no: then we're done. The system is within the limits and we can't expect > it to deliver what we want. Try to engineer a better system then. > ++ if yes: then we might start to hunt down the individual parts and find out > which part isn't up to the spec. > > As a personal note -- I'd love to engage more into that topic. It looks like > quite a challenge. But I should rather try to stay clear, as I'm already > loaded > with lots of other stuff, which is not only challenging, but kind of a > responsibility I took on. 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. 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. Cheers! Ralf _______________________________________________ 64studio-users mailing list [email protected] http://lists.64studio.com/mailman/listinfo/64studio-users
