One mouse click, 2 PC's

[Spehro Pefhany]

Is there any practical way that would enable me to use a single mouse
click in order to start a sequence at exactly the same time on two
separate PC's (identical units)?

I suppose this means hacking into the mouse lead itself, but how to
find the relevant wires?

Ken Ingram

You could take two cheap mice apart and wire a DPST momentary switch
with one Normally Open (NO) contact across each "click" switch (left
or right, whatever) and then you can position each mouse cursor where
it should go then hit the "double click" pushbutton.

It won't be "exactly" at the same time, but pretty close by PC
standards.

You won't be able to easily accomplish anything useful fiddling with
the wires leading directly to the mouse.

An alternative would be to use devices called "wedges".

 

[Archimedes' Lever]

You could take two cheap mice apart and wire a DPST momentary switch
with one Normally Open (NO) contact across each "click" switch (left
or right, whatever) and then you can position each mouse cursor where
it should go then hit the "double click" pushbutton.

It won't be "exactly" at the same time, but pretty close by PC
standards.

You won't be able to easily accomplish anything useful fiddling with
the wires leading directly to the mouse.

An alternative would be to use devices called "wedges".

Would it not be easier to simply jump online and DL the spec sheet for
the interface involved? D'oh!

 

[Nobody]

Is there any practical way that would enable me to use a single mouse
click in order to start a sequence at exactly the same time on two
separate PC's (identical units)?

I suppose this means hacking into the mouse lead itself, but how to
find the relevant wires?

Communication (whether PS/2 or USB) between a mouse and a PC is two-way,
so you can't just "fork" the wires.

You would need to use two mice, sharing a common switch.

Even then, you may find that the two PCs are slightly out of sync due to
latency in processsing the clicks.

 

[Archimedes' Lever]

Communication (whether PS/2 or USB) between a mouse and a PC is two-way,
so you can't just "fork" the wires.

You would need to use two mice, sharing a common switch.

Or mechanical switch actuator (a pair of fingers).

Even then, you may find that the two PCs are slightly out of sync due to
latency in processsing the clicks.

Somebody finally got it right.

It would not be much, but he did not specify how much "at the same
time" resolution he wanted.

 

[Archimedes' Lever]

Interrupts aren't polled. Don't you even know the english word
"interrupt"?

They are nowadays. x86 hardware is ALL tertiary to the PCI bus now, and
IT manages ALL those "hard interrupts" you retarded pussies have such a
hard on about.

You were all lost the moment you jumped onto this bandwagon, and many
of you are even too stupid to know why.

 

[George Jefferson]

Is there any practical way that would enable me to use a single mouse
click in order to start a sequence at exactly the same time on two
separate PC's (identical units)?

I suppose this means hacking into the mouse lead itself, but how to
find the relevant wires?

Ken Ingram

I suggestion you get really good at clicking with your other hand and get
another mouse and really practice on that timing!

 

[Greg Hanson]

On a serial port mouse, it'll work; just be sure your mouse can drive
two
serial receivers with a big enough signal. A Y-cable might be
enough,
not even any reason to open the mouse.

Thank you to all those who have kindly posted replies on this topic.

My reason for doing this is to synchronize two sets of stereo signals
(audio) ... one set generated in software in each identical PC
(Celerons). This is because I can find no affordable device that will
record and playback simultaneously FOUR separate WAV or MP3 files.

If there are, somebody please let me know.

Since all generated signals are within the audio spectrum, I suspect
interrupt and polling will not be significant factors.

All things considered though, the above suggestion of wiring a single
SERIAL mouse to both ports seems like the most straightforward option
so far. This is intended to activate the "play" button of the software
audio signal generator.

Greg Hanson

 

[Tim Watts]

He's used "non-polled" to mean "interrupt driven," e.g., that "when this
here signal line is asserted, there's some hardware mechanism in place
that diverts the CPU to run off and execute a certain chunk of code as
immediately as possible" -- vs. "polled" which is generally understoof
as a chunk of code that's being executed on a regular basis (due to a
timer overflow or similar) that specifically checks an I/O line.

In general interrupt-driven approaches have lower latencies between
"something happening" and the code that handles that "something" being
executed. Another benefit of interrupt-driven I/O is that when no
devices require attention, on CPU cycles whatsoever are spent worrying
about hose devices... whereas with polled I/O you're chewing up some CPU
cycles (although often a negligible percentage) verifying that, ah, OK,
none of the devices need any attention.

The USB *bus* actually *is* polled, but the chipsets that interface to
it generally perform that polling in hardware and then interrupt the
main CPU if anything "interesting" has occurred. In a very real sense,
a USB bus controller is a rudimentary I/O co-processor: It takes care of
the drudge work of polling and hence provide the benefits of
interrupt-driven I/O to the main CPU.


I don't think you can say that without specifying a polling rate, and
certainly the distributions are different: Interrupt-driven I/O has
latencies that peak at some small value and then a "long tail" that's
created when interrupts are being held off for one reason or another.
Polling I/O has latencies that are very close to a uniform distribution.

Personally I find polling using the main CPU distasteful once it hits
more than about 10Hz.

---Joel

Not to mention that some OSes (specifically Linux, because I know it
does) implement many device drivers as a bottom-half and top-half model.
The top-half gets the interrupt and deals (in as short a time as
possible) the absolute minimum to make the device happy (like emptying a
limited capacity buffer into RAM or noting some state) then signals the
bottom-half to come along and do the long slow boring processing when it
can. As the bottom-half is implemented as a kernel tasklet which might
conceivably require the further services of a kernel thread or possibly
even a user space handler there are no guarantees that being "interrupt
driven" means it is serviced to completion in a microsecond.

 

[Archimedes' Lever]

Uh-huh..... then explain how the average microprocessor services its
interrupts when more than one interrupt are pending!!

You will find that on most devices, the interrupts are priortized
(either in hardware, or in user-configurable software registers that
control the interrupt hierarchy).
The net effect of either yields delays that are quite similar to what
you would expect from polling.

-mpm

In other words, they *are* "hard" interrupts WHEN they do get polled,
which they always eventually will, but it is a round robin polling
regardless.

Bwuahahahahahahahahahaha!

 

[Archimedes' Lever]

The "It's dead, Jim! I'm a country doctor, not a rodent reviver!
D-con" ;-)

And you're an angry old fucktard, not a civil electrical engineer.

 

[Tim Watts]

Not to mention that some OSes (specifically Linux, because I know it
does) implement many device drivers as a bottom-half and top-half model.
The top-half gets the interrupt and deals (in as short a time as
possible) the absolute minimum to make the device happy (like emptying a
limited capacity buffer into RAM or noting some state) then signals the
bottom-half to come along and do the long slow boring processing when it
can. As the bottom-half is implemented as a kernel tasklet which might
conceivably require the further services of a kernel thread or possibly
even a user space handler there are no guarantees that being "interrupt
driven" means it is serviced to completion in a microsecond.

On an aside, too many interrupts can of course impair system performance.
Some of the Intel gigabit ethernet chipsets employs an optional scheme
called interrupt-coalescing which, instead of causing an interrupt on
every packet received (for example), can instead buffer incoming packets
and fire an interrupt once every n-packets. At least one of the linux
ethernet device drivers even has an option to switch it into polled
handling for high throughput (note, not low latency) devices as it is
deemed to give a net gain in efficiency for some scenarios.

 

[Archimedes' Lever]

Simply drop a second audio card into your first PC.

There are set-ups out there with four.

 

[Greg Hanson]

Simply drop a second audio card into your first PC.

OK, but the commercial audio editing software I use (CoolEdit) only
generates a stereo signal. If I open a second instance of it, how do I
force it to address the second soundcard?

There appears to be nothing in the program itself that will enable
this. IOW if you change the default device in one instance, it changes
it in all.

Any suggestions?

Another respondent mentioned 4 track recorders. My associate Ken (the
OP) said he looked into these and, while they record 4 channels for
mixing purposes, only 2 can be output, as a conventional stereo
signal. At least for the lower cost models examined.

Greg Hanson

 

[Archimedes' Lever]

OK, but the commercial audio editing software I use (CoolEdit) only
generates a stereo signal. If I open a second instance of it, how do I
force it to address the second soundcard?

Run Linux and one of the many hugely advanced mixing studios that are
saturating the community. Lots of FREEdom there.

There appears to be nothing in the program itself that will enable
this. IOW if you change the default device in one instance, it changes
it in all.

Just about any live distro has some sound tools, but there are sound
and composition specific distros out there where you boot it up, and you
have 64 tracks at your disposal. Or whatever.

Any suggestions?

See above.

 

[Archimedes' Lever]

Note that you probably should prefer a single audio card over several if your
goal is to keep everything in lock-step sync: If you use multiple cards,
they'll likely each have their own clock generators that will be ever so
slightly different in frequency and hence the audio output will slowly get out
of sync unless your software is very much on top of this and can insert or
delete samples to "fix" it (I'd be surprised if most software had such an
option...)

Note that switching latencies in such a scenario will be very short
with respect to audio frequencies and events, so it should be fine for
his intents.

Their not really synched 'lock-step-synch' is likely pretty damned
close, like single digit milliseconds.

 

[Archimedes' Lever]

Most soundcards these days support 5.1 audio, so perhaps you could just use
front L+R and rear L+R for your four outputs?

He said Cooledit does stereo.

 

[Archimedes' Lever]

Even under Linux I would strongly suspect that
two IDENTICAL computers could never be
perfectly synchronized.

Cluster arrangements have to be.

Where 'perfectly' has a definition.

One you failed to define and eluded to being a number which is not
easily attainable in any system.

 

[Archimedes' Lever]

The "other Greg Hanson" in Cedar Rapids, Iowa

Your crap was pretty much a bunch of mumbling. Learn how to quote the
person you are replying to.

You ain't 'all that'. You don't even come close.

 

[Mike Warren]

My reason for doing this is to synchronize two sets of stereo signals
(audio) ... one set generated in software in each identical PC
(Celerons). This is because I can find no affordable device that will
record and playback simultaneously FOUR separate WAV or MP3 files.

This sort of thing is my field of expertise. I assume you are using
Windows since you mentioned Cool Edit.

1/ Are these WAV/MP3 files or does a signal need to be captured
in real time?

2/ What version of Windows are you using?

3/ How old is your computer? Do you know if the sound card is 5.1
channel compatible?

 

[Archimedes' Lever]

I hear a faint whiny sound like a mosquito.

All gmail Usenet retards should be removed from the gene pool!

You are one such retard.