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 User

 
 
LinkBack Thread Tools
 
Old 06-25-2010, 10:50 PM
Ralf Mardorf
 
Default basic MIDI note-on/note-off questions

On Fri, 2010-06-25 at 16:18 -0600, Gustin Johnson wrote:
> On 10-06-25 03:31 PM, Ralf Mardorf wrote:
> > On Fri, 2010-06-25 at 15:05 -0600, Gustin Johnson wrote:
> >> On 10-06-25 02:02 PM, Ralf Mardorf wrote:
> >>> Hi
> >>>
> >>> I guess no answer is an answer .
> >>>
> >> Not necessarily. You could be asking the wrong question and or in the
> >> wrong place.
> >>
> >>> There are several ways to program for asynchronous serial interfaces,
> >>> but there's only one way regarding to real time MIDI.
> >>>
> >>
> >>> When I programmed on Assembler in the 80ies I directly talked to the
> >>> UART, and request CTS/RTS for every single byte.
> >>>
> >>> It's also possible not to use CTS/RTS for every single byte, but than
> >>> you need to add headroom for the time. While it wouldn't be such a
> >>> drama, if 1ms headroom would be 1ms, it's a drama because for such a
> >>> long time a lot of IRQs are able to produce jitter, but a constant
> >>> latency.
> >>>
> >>> I guess the MIDI coders for Linux did a bad job. I might be wrong, but
> >>> as I said before, getting no answer is getting an answer .
> >>
> >> I would hesitate to jump to this conclusion if I were you. I would also
> >> rephrase this. Saying someone did a bad job but providing no real proof
> >> is not usually a successful strategy in the open source world.
> >>
> >> Also getting no answer may indicate a completely different problem.
> >>
> >>> Hopefully I'm just paranoid and wrong .
> >>
> >> I don't think paranoia is the right word.
> <snip>
> >
> > The question is very simple. The UART (used by MPU etc.) in the 80ies
> > very seldom the ACIA too, can be used directly on Assembler or by
> > grotesque detours and C must not be the bad, if one knows what he does
> > on C. At least I wonder about the statements from Paul Davis, the Guru
> > for RT Linux. It is completely nonsense what he has written, that there
> > anything regarding to the time is fixed for an asynchronous serial
> > interface. If you take care about the CTS/RTS there's nothing fixed. He
> > doesn't know what he was talking about. I do know what I'm talking
> > about, hence it was my job and in addition I did what today is called
> > FLOSS myself a long time before there was Linux rt.
>
> Did the hardware you use in any way resemble modern hardware? Personal
> attacks are probably not the best way to get the help. Just a little a
> suggestion.
> >
> > The big OZ Mr. Davis did wrote nonsense, idiotic stuff, he complete has
> > no knowledge about RT MIDI regarding to software + hardware.
> >
> <snip>
> > PS: Is MIDI for Linux an RT thread? Is it? Or could e.g. the graphics
> > interrupt the movement from ALSA seq to the MIDI interface?
> >
> I don't know, but I bet the answer is in the source code.
>
> > I've got no knowledge about Linux, but I do have knowledge about
> > hardware + software regarding to music and especially regarding to MIDI.
>
> >
> > What's bad with my question?
>
> I am not sure to which vague question you are referring.
> >
> > Jitterless MIDI does mean you have to program for MIDI rt too, this
> > means you request CTS/RTS and do write one byte directly to the MIDI
> > interface. If it should be done on Linux in any other way, than it's
> > incompetent programed.
> >
> So, how was it done? You have oversimplified the equation.
>
> > ALSA seq might not be the bad, but how is it handled to talk to the
> > UART? Is runtime lib a talking to runtime lib b? If so the coders did a
> > bad job. This isn't the way you can handle an asynchronous serial
> > interface for real time.
> >
> You know, I am not sure how it was done. I am sure the answer is there
> in the source code if you want to find out.


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

I've forgotten, the C64 was limited to 64kiB and you even don't need
1kiB to program a stable sequencer.

It takes weeks to read around 1kiB on Assembler. Do you know how much
MiBs of Assembler are produced by a C compiler?

1. I can't read Linux C.
2. Even if I would be able to do it, this isn't important ...

What does the machine code, the run time libs do, regarding to real time
for MIDI?

Why should I read the code, when i could ask the coders? And now the
bomb drops! There is no answer, because they don't know what they do,
resp. what they use. They just use some headers, believe in rt for audio
and don't care about oldish asynchronous slow interfaces and the way the
Linux libs they do handle does. Instead they say it's oldish and any
failure is caused because of the oldish technically specifications. They
are wrong, oldish sequencers for 65xx, 68xxx microchips don't have
jitter, because much more gifted people but me, e.g. Gerhard Lengeling
(I learn a lot by hacking his codes), but also idiots like me, did
program a compiletly other and better, perfect way.

I can't read Linux code, it's cryptic and doesn't say anything about the
translation to the machine code, but machine code is required, resp.
absolut knowledge about how the c code is translated to machine code.

Regarding to Linux you have much more knowledge, but I do have, but you
doesn't have any knowledge regarding to oldish asynchronous MIDI
interfaces, that needs to be controlled on rt.

You can't just read the C, C++ or what ever compiler code. You also need
to have knowledge about the way the code is translated to machine code
(= Assemble if you prefer it the human readable way).

I asked about this!

Cheers,

Ralf

_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-28-2010, 04:51 AM
Ichthyostega
 
Default basic MIDI note-on/note-off questions

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

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.

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.

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?
- - what protocols are involved on what parts, which could be relevant?
- - 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.

Cheers,
Hermann





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

iEYEARECAAYFAkwoKmsACgkQZbZrB6HelLK6bgCfdGiDTnZjNG jEt2fMepUAF/yh
iZEAoKGAKyC8DTG7KG4ZX6b3iI2s3Ybx
=2tHT
-----END PGP SIGNATURE-----
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-28-2010, 10:22 AM
Daniel James
 
Default basic MIDI note-on/note-off questions

Hi Ralf,

> Why should I read the code, when i could ask the coders?

My answer would be: because it could help you ask the right questions.
Asking the right questions, in the right way, will elicit better answers.

You've clearly done a lot of work in identifying the problem of MIDI
jitter on GNU/Linux, and making other developers and users aware of it.

To get to the next level - where you could write a patch that would be
considered for adoption by ALSA, or another relevant part of GNU/Linux,
would take more work still. If you are personally prepared to take on
this major challenge, I would encourage you to do so. You might like to
read http://lwn.net/Kernel/LDD3/ for a start.

> I can't read Linux code, it's cryptic

And yet some people do read the code, and submit patches that work. So
it can be done.

Cheers!

Daniel
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-29-2010, 07:51 AM
Ralf Mardorf
 
Default basic MIDI note-on/note-off questions

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
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-29-2010, 07:54 AM
Ralf Mardorf
 
Default basic MIDI note-on/note-off questions

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

In the middle of next month, than I might have the money for a new hard
disk drive or not .

_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 06-29-2010, 08:03 AM
Ralf Mardorf
 
Default basic MIDI note-on/note-off questions

On Mon, 2010-06-28 at 11:22 +0100, Daniel James wrote:
> Hi Ralf,
>
> > Why should I read the code, when i could ask the coders?
>
> My answer would be: because it could help you ask the right questions.
> Asking the right questions, in the right way, will elicit better answers.
>
> You've clearly done a lot of work in identifying the problem of MIDI
> jitter on GNU/Linux, and making other developers and users aware of it.
>
> To get to the next level - where you could write a patch that would be
> considered for adoption by ALSA, or another relevant part of GNU/Linux,
> would take more work still. If you are personally prepared to take on
> this major challenge, I would encourage you to do so. You might like to
> read http://lwn.net/Kernel/LDD3/ for a start.
>
> > I can't read Linux code, it's cryptic
>
> And yet some people do read the code, and submit patches that work. So
> it can be done.
>
> Cheers!
>
> Daniel

Bookmarked. It's not that easy to learn C, C++, especially it's hard to
get knowledge about what 'cryptic' code is good and what is bad
regarding to rt.

Best,

Ralf


_______________________________________________
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 10:57 AM.

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