FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > 64 Studio > 64 Studio Developer

 
 
LinkBack Thread Tools
 
Old 06-29-2010, 02:21 PM
Ralf Mardorf
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

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 rout 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:

## see [1] easier to read for C64 Assembler coders

Load register_with_the_information_if_there_is_a_byte_f or
an_MIDI_event_to_a_'memory'_register

LSR #to check if the flag is set

Branch
back_to_load_register_until_the_flag_isn't_cleared _or_as_long_it's_set

Load MIDI_event_byte_from_data_register_to_a_'memory'_r egister

##

For this loop IRQs for other programs were allowed, e.g. to ask
information from the QWERTY keyboard.
Then you go on:

## [2]

SEI # to disable IRQs, now the following rout has 100% rt priority

# some code to process data

CLI # to enable IRQs

##

This would be hard real time. While the 6502 has got 3, what I called
here 'memory' registers, a, x and y (I guess a is an own register, some
days ago I thought it was for the stack) an AMD might have much more of
those registers and instead of load and store loops there might be a
move command.

The parallel port of our PCs seems to have a relativ directly connection
to the PCs main bus, just for 8 bits (1 byte, but 32 or 64 bits, but we
only need those 8 bits for MIDI), perhaps it's easy to connect a 64
MIDInterface to the parallel port, perhaps just some TTLs are needed,
perhaps I'm a little bit too naiv.

So if there should be a way to disable and enable interrupts for
Intel/AMD too, it should be possible to do the same kind of programming
as for the C64.

IIUC for Intel/AMD IRQs aren't IRQs, but NMIs?!

Cheers!

Ralf

[1] I once did a MIDI extension for SpeechBasic to program a real time
MIDI sound sampler on BASIC

$1810 LDA $DEO6
$1813 LSR
$1814 BCC $1810
$1816 LDA $DE07; read MIDI event byte, usually followed by RTS

[2]

$181A SEI; disable IRQs

;the MIDI program

$183C CLI; enable IRQs, usually followed by RTS

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 06-29-2010, 07:09 PM
Ralf Mardorf
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

On Tue, 2010-06-29 at 16:21 +0200, Ralf Mardorf wrote:
> 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 rout 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:
>
> ## see [1] easier to read for C64 Assembler coders
>
> Load register_with_the_information_if_there_is_a_byte_f or
> an_MIDI_event_to_a_'memory'_register
>
> LSR #to check if the flag is set
>
> Branch
> back_to_load_register_until_the_flag_isn't_cleared _or_as_long_it's_set
>
> Load MIDI_event_byte_from_data_register_to_a_'memory'_r egister
>
> ##
>
> For this loop IRQs for other programs were allowed, e.g. to ask
> information from the QWERTY keyboard.
> Then you go on:
>
> ## [2]
>
> SEI # to disable IRQs, now the following rout has 100% rt priority
>
> # some code to process data
>
> CLI # to enable IRQs
>
> ##
>
> This would be hard real time. While the 6502 has got 3, what I called
> here 'memory' registers, a, x and y (I guess a is an own register, some
> days ago I thought it was for the stack) an AMD might have much more of
> those registers and instead of load and store loops there might be a
> move command.
>
> The parallel port of our PCs seems to have a relativ directly connection
> to the PCs main bus, just for 8 bits (1 byte, but 32 or 64 bits, but we
> only need those 8 bits for MIDI), perhaps it's easy to connect a 64
> MIDInterface to the parallel port, perhaps just some TTLs are needed,
> perhaps I'm a little bit too naiv.
>
> So if there should be a way to disable and enable interrupts for
> Intel/AMD too, it should be possible to do the same kind of programming
> as for the C64.
>
> IIUC for Intel/AMD IRQs aren't IRQs, but NMIs?!
>
> Cheers!
>
> Ralf
>
> [1] I once did a MIDI extension for SpeechBasic to program a real time
> MIDI sound sampler on BASIC
>
> $1810 LDA $DEO6
> $1813 LSR
> $1814 BCC $1810
> $1816 LDA $DE07; read MIDI event byte, usually followed by RTS
>
> [2]
>
> $181A SEI; disable IRQs
>
> ;the MIDI program
>
> $183C CLI; enable IRQs, usually followed by RTS

Hm? The C64 MIDI interface is absolutely connected to the main bus. This
seems to be important.

Disabling the interrupt and enabling again for processing was needed,
because the C64 was slow. This is comparable to Linux for MIDI inside
the studio in the box. Linux MIDI inside the studio in the box is ok.

So, there must be an issue for the handoff to the hw MIDI software
interface or the hw MIDI hardware itself, resp. to the protocols or the
hardware/software.

Jitter seems to be caused at the latest handoff.

In my case obviously the USB protocol seems to be the PITA.

For the C64 I couldn't see any issue regarding to IRQs, there were just
issues regarding to the processing of MIDI data + IRQs, but not when
calling the MIDInterface.

IMO it should be avoided to keep in contact to the UART by any software
interface, this must be done directly.

I guess the parallel port is bad too, perhaps PCI express might solve
this.

Dunno .

Ralf

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 06-29-2010, 07:20 PM
Ralf Mardorf
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

On Tue, 2010-06-29 at 21:09 +0200, Ralf Mardorf wrote:
> On Tue, 2010-06-29 at 16:21 +0200, Ralf Mardorf wrote:
> > 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 rout 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:
> >
> > ## see [1] easier to read for C64 Assembler coders
> >
> > Load register_with_the_information_if_there_is_a_byte_f or
> > an_MIDI_event_to_a_'memory'_register
> >
> > LSR #to check if the flag is set
> >
> > Branch
> > back_to_load_register_until_the_flag_isn't_cleared _or_as_long_it's_set
> >
> > Load MIDI_event_byte_from_data_register_to_a_'memory'_r egister
> >
> > ##
> >
> > For this loop IRQs for other programs were allowed, e.g. to ask
> > information from the QWERTY keyboard.
> > Then you go on:
> >
> > ## [2]
> >
> > SEI # to disable IRQs, now the following rout has 100% rt priority
> >
> > # some code to process data
> >
> > CLI # to enable IRQs
> >
> > ##
> >
> > This would be hard real time. While the 6502 has got 3, what I called
> > here 'memory' registers, a, x and y (I guess a is an own register, some
> > days ago I thought it was for the stack) an AMD might have much more of
> > those registers and instead of load and store loops there might be a
> > move command.
> >
> > The parallel port of our PCs seems to have a relativ directly connection
> > to the PCs main bus, just for 8 bits (1 byte, but 32 or 64 bits, but we
> > only need those 8 bits for MIDI), perhaps it's easy to connect a 64
> > MIDInterface to the parallel port, perhaps just some TTLs are needed,
> > perhaps I'm a little bit too naiv.
> >
> > So if there should be a way to disable and enable interrupts for
> > Intel/AMD too, it should be possible to do the same kind of programming
> > as for the C64.
> >
> > IIUC for Intel/AMD IRQs aren't IRQs, but NMIs?!
> >
> > Cheers!
> >
> > Ralf
> >
> > [1] I once did a MIDI extension for SpeechBasic to program a real time
> > MIDI sound sampler on BASIC
> >
> > $1810 LDA $DEO6
> > $1813 LSR
> > $1814 BCC $1810
> > $1816 LDA $DE07; read MIDI event byte, usually followed by RTS
> >
> > [2]
> >
> > $181A SEI; disable IRQs
> >
> > ;the MIDI program
> >
> > $183C CLI; enable IRQs, usually followed by RTS
>
> Hm? The C64 MIDI interface is absolutely connected to the main bus. This
> seems to be important.
>
> Disabling the interrupt and enabling again for processing was needed,
> because the C64 was slow. This is comparable to Linux for MIDI inside
> the studio in the box. Linux MIDI inside the studio in the box is ok.
>
> So, there must be an issue for the handoff to the hw MIDI software
> interface or the hw MIDI hardware itself, resp. to the protocols or the
> hardware/software.
>
> Jitter seems to be caused at the latest handoff.
>
> In my case obviously the USB protocol seems to be the PITA.
>
> For the C64 I couldn't see any issue regarding to IRQs, there were just
> issues regarding to the processing of MIDI data + IRQs, but not when
> calling the MIDInterface.
>
> IMO it should be avoided to keep in contact to the UART by any software
> interface, this must be done directly.
>
> I guess the parallel port is bad too, perhaps PCI express might solve
> this.
>
> Dunno .
>
> Ralf

USB is done similar to TCP/IP? By buffered packages? But not directly?
At what speed? A rhetorical question, I'll search the web myself.

But serious, how many instances are between the sequencers software
output and the hw MIDI output? 20 libs, the kernel, the BIOS and 100
chips?

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 06-30-2010, 04:34 AM
Ichthyostega
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

-----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.

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.

* 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.


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.

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 fr 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?)

What are you doing?
Playing a soft sequencer to external hardware MIDI? 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?

- 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



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwqyVUACgkQZbZrB6HelLICXwCfTsVTFPnb5/GK9xMvEZP+BnZG
F/YAoLVtlL10ehz7UZUj1Eq5ScxLYM0D
=0Rfz
-----END PGP SIGNATURE-----
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-30-2010, 05:15 AM
Ralf Mardorf
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

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 <ralf.mardorf@alice-dsl.net>
To: Niels Mayer <nielsmayer@gmail.com>
Cc: Linux Audio Developers <linux-audio-dev@lists.linuxaudio.org>
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
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-30-2010, 08:27 AM
Ralf Mardorf
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

On Wed, 2010-06-30 at 03:38 -0400, a gifted man wrote (I'll send it Bcc
to him too):

> You did it because it was easy to do. Modern cpu's have a structured IRQ
> setup that can and is expandable to at least 255 interrupts. And on the
> 6502, you didn't expect it to go fetch the mail in the background, monitor
> the HD's temps, maintain a fancy realtime video display and all the rest of
> the about 350 processes running on this box at the moment.

I would be fine with a X free Linux just using a ncurse 'GUI' for a MIDI
sequencer (no soft synth) + hard disk recorder .

Usually I'm not running any email client when I'm 'playing' music and I
don't wish 100 deamons running that protect me against all the other
non-existing users and Internet attacks.

There are no other users, there's no Internet, there's just the wish to
have a tool for music.

I always wounder about arguments regarding to multitasking and security.

My home studio computer isn't an Internet server for 100 people and
there's no security needed.

Arguments that producing music might be less good, but OTOH I can
produce music (less good) + use the same computer as a databank for 100
other users at the same time, while having a 100% security against any
attack are unimportant to me.


Ralf



_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 06-30-2010, 08:33 AM
Ralf Mardorf
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

PS:

http://3.bp.blogspot.com/_p8XM2K9FDNY/RvqqueJJdXI/AAAAAAAAAG4/jqYVwUTKe5g/s320/storchmesser.jpg

There's a German idiom, the "Eierlegendewollmilchsau", on English the
"lay-an-egg-wool-and-milk-giving-pig". Usually I don't need all this for
making music.

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 06-30-2010, 08:38 AM
Daniel James
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

Hi Ralf,

> Assumed it's not broken, than for my Terratec EWX 24/96 there's an issue
> for the pin allocation.

Are you using a 15-pin DIN (gameport) to 2 x 5 pin DIN convertor cable
with an optical isolator inside? I seem to recall the isolator was
required when using a gameport (for galvanic isolation?)

> Do the ports for most sound cards usually have the common pin
> allocation?

I think gameport MIDI was a standard from the Soundblaster range, which
other soundcards of the time adopted. According to the English version
of the manual for your card:

http://www.terratec.net/en/driver-and-support/faq_37196.html?selectproduct=EWX%2024/96

the pin i/o is standard for gameport MIDI.

Cheers!

Daniel
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-30-2010, 08:51 AM
Ralf Mardorf
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

On Wed, 2010-06-30 at 09:38 +0100, Daniel James wrote:
> Hi Ralf,
>
> > Assumed it's not broken, than for my Terratec EWX 24/96 there's an issue
> > for the pin allocation.
>
> Are you using a 15-pin DIN (gameport) to 2 x 5 pin DIN convertor cable
> with an optical isolator inside?

The original cable I did solder and use with an oldish on-board gameport
was without optical isolation. For the Terratec I added opto-couplers.

> I seem to recall the isolator was
> required when using a gameport (for galvanic isolation?)

Correct, opto-couplers are a standard for MIDI to do galvanic isolation.

> > Do the ports for most sound cards usually have the common pin
> > allocation?
>
> I think gameport MIDI was a standard from the Soundblaster range, which
> other soundcards of the time adopted. According to the English version
> of the manual for your card:
>
> http://www.terratec.net/en/driver-and-support/faq_37196.html?selectproduct=EWX%2024/96

Thank you, on the quick I didn't found information about the pin
allocation, but I'll read it again in the evening.

> the pin i/o is standard for gameport MIDI.

If so the card might be broken all the time, it's a gift, or I might
have killed it, because I did a bad soldering ... I didn't notice when
my eyes switched from hawk's eyes to mole and there were issues for the
jack when I added opto-couplers, because of my soldering.

>
> Cheers!
>
> Daniel

Cheers!

Ralf


_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-30-2010, 08:52 AM
Daniel James
 
Default Information wanted regarding to differences between oldish CPUs and modern CPUs regarding to IRQ handling

Hi Hermann,

> 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.

That hasn't been my experience with Windows 7 at a neighbours' house.
Installed scanners disappear on reboot, the printer driver resets itself
to US Letter paper instead of A4, and the wireless network always drops
the connection after a minute or two.

I think it's really a difference of perception. In the case of the
wireless connection problems, Microsoft's response is that you should
upgrade your router firmware - for a (probably GNU/Linux) router that
works fine with XP and all other OS's. So they take a bug in Windows 7
and redefine it as a router bug - your problem, not theirs. They have
the commercial muscle to force all third party suppliers to bend to
their will, and provide work arounds for the bugs in their product. I
doubt it's much different for third party suppliers in the MacOS market
- do things Apple's way, or not at all.

No GNU/Linux distribution has that amount of influence in the desktop or
laptop market. Some have a certain amount of influence in the server or
embedded markets, but it's much more like a level playing field between
all the parties. So if things get fixed, it's more likely to be because
of a consensus, rather than coercion.

Cheers!

Daniel
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 

Thread Tools




All times are GMT. The time now is 01:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org