*start*
00846 00024 US 
Date:  7-Feb-83 11:16:04 PST (Monday)
From: JMaloney.PA
Subject: Auburn Board
To: Verplank
cc: NDSmith, Stewart, JMaloney.PA

Bill,
   The part we need to make the Auburn boad fully functional is an HA2425 Sample/Hold. I have no idea where to find one. I bought two extra LM377 audio amplifier chips at Radio Shack and replaced the one in the Auburn board but that turned out not to be the problem.

  The Auburn board in AnotherBurdock will make the signal Preamp2 available until we replace the bad HA2425 (There are two Sample/Holds on the DAC output. I just swapped 'em for now; maybe that's good enough. Does anyone use Preamp2 for anything?)

   Got any other broken Auburn boards??

Larry, Nancy,
   Do either of you know if there is a supply of HA2425's floating around either here or at PARC? Thanks!
				-- John
*start*
01359 00024 US 
Date:  7-Feb-83 11:30:06 PST (Monday)
From: JMaloney.PA
Subject: Auburn Help
To: Stewart

Larry,
   As you probably guessed from my previous message, I've gotten interested in digital music again. I'm not sure how long I will have free cycles to spend on this outside interest, unfortunately.
   I need some info on the Audio.bcd program and the capabilities of the Auburn board. Somewhere in the documentation I have on it, it says it will sample at 20K samples/second, up to 12 bits/sample, and has some sort of anti-aliasing filter on the output. What I'd like to do is to get the maximum bandwidth I can, of course, so I'd like to know how set the Auburn parameters so that I can sample at 20K, filter at 10K hertz, and use 12 bit samples. Also, can the Alto disk keep up with that bandwidth? My plan is to create a "sound file", ftp it over to the Alto, and dump it to the DAC. I've already tried using the BSP to stream the data from my Dandelion and I got dropouts (I postulate because of delays in the internetwork gateway between the 10 and 3 MBit ethernets.)
   I would rather not have to write anything in AltoMesa, if possible.
   Thanks for any hints/help you can give me. Since this is not an officially sanctioned project, you should feel perfectly free to say that you have no time to answer my questions.

				-- John
*start*
02388 00024 US 
Date: 7 Feb. 1983 4:11 pm PST (Monday)
From: Stewart.PA
Subject: Re: Auburn Help
In-reply-to: Your message of 7-Feb-83 11:30:06 PST (Monday)
To: JMaloney
cc: Stewart

I don't really know the ultimate limits of Auburn's sampling capabilities.  It might be as much as 20 kHz.

The sampling clock is generated by dividing down from the Alto clock at 5.88 MHz.  Some collection of integer divisions of 5.88 are available.  See the auburn manual.  The Audio.bcd program has a command 'N which accepts a sample rate and sets up the hardware according to some algorithm about the closest sampling rate of those available.  I don't remember the details, but the algorithm is likely to break down before 20 kHz.  That could be fixed in Alto-Mesa.

[ My recollection is that there is a two stage division process, first by a small integer in 1..8 or so that generates the clock for the filter chips, and then another division by ~30 to generate a frequency 4 times the desired sample rate.
]

Another limit to fast sampling is the length of the microcode loop that runs every sample time.  There is more microcode than when the early documentation was written, so the limit may be lower.

The built in low-pass filter is an Intel 2912 switched capacitor filter.  When the chip is fed 1.536 MHz it cuts off at 3.3 kHz.  This is what you get if you type "N(yquist) 8000" to Audio.bcd.  Within some range, the cutoff frequency scales with the clock rate, but it seems unlikely to me that you can triple the clock to the 2912 and have it filter at 10 kHz.  I don't know.

You can switch the filter out of the circuit however, and use an external low-pass filter set to whatever you like.  Audio.bcd may or may not have enough built in smarts to do this without modification.

I do not know what the Alto disk limitations are.  I don't remember Audio.bcd using any particularly fancy disk I/O code, so it can probably be improved.

If you want to come over here and poke at it sometime, I can help you make any needed modifications to Audio.bcd (excluding major renovations of I/O performance please!).

20 kHz samples at 16 bits/sample (Auburn packages 12 bits into a 16 bit word) takes roughly 80 disk pages per second.  A double Alto disk then holds 100 seconds or so.

It should be possibile to get network performance better than than 320 kilobits, although hard.

	-Larry

*start*
00533 00024 US 
Date: 8 Feb. 1983 3:59 pm PST (Tuesday)
From: ornstein.PA
Subject: Etherphone Legal Questions
To: Swinehart, Stewart, Carothers
cc: ornstein

There are two areas in which we need to consult with Doug.

	1. The whole question of what and whether to patent

	2. The issue of registration 

We will have to spend some time to begin with bringing Doug on board of the
design and plans. I have made a tentative date with him for the morning (I
suggest 10 AM) of Thursday, Feb 24.  Is that OK with everyone?  

S.

*start*
00555 00024 USm
Date: 11 Feb. 1983 4:21 pm PST (Friday)
From: ornstein.PA
Subject: Re: On contemplating Dan Swinehart's desk
In-reply-to: Your message of 21-Jan-83 18:26:57 PST
To: kolling
cc: CSL^, VoiceProject^
Reply-To: ornstein

		What you must realize that you've seen
		's a telephone that's really keen.
		Though pink, or blue, or billious green,
		it'll talk to where you've never been

		Now I can't tell, 'tho I be cursed 
		Who'll get to Etherphoning first.
		But reading through your poem fast,
		I think I know who'll get hers last.

*start*
04337 00024 US 
Date: 14 Feb. 1983 3:30 pm PST (Monday)
From: ornstein.PA
Subject: Voice Plans
To: Stewart, Swinehart
cc: Ornstein

This is a draft copy for your corrections and additions before I send it to
VoiceProject^.  Please add clarification where I show (***).

Note the last paragraph;  I don't expect you to like it (especially you-know-who)
but I'm willing to compromise - if you really believe it is a bad idea.

S.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Dan, Larry and I met this AM to review where we stand and to develop a plan
and a schedule.  The milestone we are shooting for is the first public release of
the system - to about ten users. 

We considered Lark, Thrush, Bluejay, and Finch - listing tasks remaining,
trying to classify them as Hard, Medium, Easy - guessing at number of weeks
required to complete those of significance - and, most importantly, bounding
those things that would be included in the release as opposed to later.  Here is
what we see.

	notes:	H = hard,  M = medium,  E = Easy, U = Unknown.

		Number in () is (conservative) guess at number of weeks
		required for task

		(X) = maybe someone else will do this - at least lend help

		In each area, tasks above the line .-.-.-.-.-. are deemed necessary to
		the first release; those below the line can be worked later. 

-------------------------------------------------------------------------------
LARK 

M(3)	Reworked Monitor and Debugging facilities - the 3 wks. includes 1 wk.
	for a Teledeb Cedar pkg. which will include control of Remote debugging,
	Downloading, and Lark Booting.
M(2)	Removal of dynamic Allocation, General cleanup, Bonsai(***)
H(1)	Voice Protocol Rework
M	(Re) Registration - including implementation of watchdog timer
E	Simple changes for Thrush compatibility
E	New PC boards, case etc.
	.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

H	Further Slave programs
H	Conferencing (Multicast)
U	FCC Part 68 Registration
U 	Performance tuning

-------------------------------------------------------------------------------
THURUSH
-
H(3)	(Last) Rework -  includes Robustness, "Held" calls, Multi-party calls
M(1)	(Re) Registration
E	Message Database completion

	.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
 
M	Clean up Teleset User Interface
H	"Industrial Grade" control/Monitor panel
M	Back-door forwarding (including simultaneous front-door use)
H	Advanced Teleset PBX Features
M	Database Upgrades - RNames, Machine/Name mappings, Voice msgs./files
H	Multiple Thrushes

-------------------------------------------------------------------------------
BLUEJAY

E	Debug latest silence code (user hears silences but they're efficiently
	stored), early-stop code (user controlled playback termination)
M	New Voice Protocols

	.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

M	Silence management user options, Record/Playback management
U	Administrative matters - Backup, scavenging, garbage collection, acnting.
H	Analysis (***)
M	WorkStation voice protocols (e.g. voice to W.S. for editing)
U	Performance - can we base Bluejay on Alpine?, Dandelion - Tuning
U	Recording conversations - conference or otherwise

-------------------------------------------------------------------------------
FINCH

E(1)	Finish Simple Version

	.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

H	Client package
H(X)	Voice Msgs. in Walnut
H(X)	Squirrel Interface for Finch - White pages
H	Attendant console (receptionist)
H(X)	Tioga Interface for serious voice editing	



*	*	*	*	   CONCLUSIONS		*	*	*	*



FEB	 ---now
	|
	|
	|   6 weeks to finish work necessary for release
MAR	|   (Lark work presently looks like the gating item)
	|
	 ---Voice Dorado Arrives
	|
APR	|   Final Integration and Debug
	|
	 ---Done
	|
MAY	|   Burn In (Use by Project members)
	|
	 ---RELEASE

JUN


We believe this is a conservative schedule and secretly hope to beat it by as
much as a month - but are unwilling to say that publicly.  

I suggest that we meet regularly every two weeks from here on until the release
- to see how close we are holding to this schedule and what problems are
developing. 

S.
*start*
04183 00024 US 
Date: 17 Feb. 1983 1:11 pm PST (Thursday)
From: ornstein.PA
Subject: Voice Plans
To: VoiceProject^
Reply-To: ornstein

Dan, Larry and I met a couple of days ago to review where we stand and to
develop a plan and a schedule.  The milestone we are shooting for is the first
public release of the system - to about ten users. 

We considered Lark, Thrush, Bluejay, and Finch - listing tasks remaining,
trying to classify them as Hard, Medium, Easy - guessing at number of weeks
required to complete those of significance - and, most importantly, bounding
those things that would be included in the release as opposed to later.  Here is
what we see.

	notes:	H = hard,  M = medium,  E = Easy, U = Unknown.

		Number in () is (conservative) guess at number of weeks
		required for task

		(X) = maybe someone else will do this - at least lend help

		In each area, tasks above the line .-.-.-.-.-. are deemed necessary to
		the first release; those below the line can be worked later. 

-------------------------------------------------------------------------------
LARK 

M(3)	Reworked Monitor and Debugging facilities - the 3 wks. includes 1 wk.
	for a Teledeb Cedar pkg. which will include control of Remote debugging,
	Downloading, and Lark Booting.
M(2)	Removal of dynamic Allocation (code name: Bansai), General cleanup
H(1)	Voice Protocol Rework
M	(Re) Registration - including implementation of watchdog timer
E	Simple changes for Thrush compatibility
E	New PC boards, case etc.
	.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

H	Further Slave programs
H	Conferencing (Multicast)
U	FCC Part 68 Registration
U 	Performance tuning

-------------------------------------------------------------------------------
THURUSH
-
H(3)	(Last) Rework -  includes Robustness, "Held" calls, Multi-party calls
M(1)	(Re) Registration
E	Message Database completion

	.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
 
M	Clean up Teleset User Interface
H	"Industrial Grade" control/Monitor panel
M	Back-door forwarding (including simultaneous front-door use)
H	Advanced Teleset PBX Features
M	Database Upgrades - RNames, Machine/Name mappings, Voice msgs./files
H	Multiple Thrushes

-------------------------------------------------------------------------------
BLUEJAY

E	Debug latest silence code (user hears silences but they're efficiently
	stored), early-stop code (user controlled playback termination)
M	New Voice Protocols

	.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

M	Silence management user options, Record/Playback management
U	Administrative matters - Backup, scavenging, garbage collection, acnting.
H	Analysis -- Bluejay-resident programs to provide concise descriptions of
	some of the characteristics of utterances, at low data rates:  where the
	silences are, average loudness of each non-silent interval, and so on.
M	WorkStation voice protocols (e.g. voice to W.S. for editing)
U	Performance - can we base Bluejay on Alpine?, Dandelion - Tuning
U	Recording conversations - conference or otherwise

-------------------------------------------------------------------------------
FINCH

E(1)	Finish Simple Version

	.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

H	Client package
H(X)	Voice Msgs. in Walnut
H(X)	Squirrel Interface for Finch - White pages
H	Attendant console (receptionist)
H(X)	Tioga Interface for serious voice editing	



*	*	*	*	   CONCLUSIONS		*	*	*	*



FEB	 ---now
	|
	|
	|   6 weeks to finish work necessary for release
MAR	|   (Lark work presently looks like the gating item)
	|
	 ---Voice Dorado Arrives
	|
APR	|   Final Integration and Debug
	|
	 ---Done
	|
MAY	|   Burn In (Use by Project members)
	|
	 ---RELEASE

JUN


We believe this is a conservative schedule and secretly hope to beat it by as
much as a month - but are unwilling to say that publicly.  

I suggest that we meet regularly every two weeks from here on until the release
- to see how close we are holding to this schedule and what problems are
developing. 

S.

*start*
01408 00024 US 
Date: 20 Feb. 1983 8:16 pm PST (Sunday)
From: Stewart.PA
Subject: Problems encountered with LarkMon
To: VoiceProject^.pa
cc: Taft, Boggs, Murray

The new monitor, LarkMon, is working.  There are more things to be added, and the Cedar end is not done yet.

Major bugs encountered during creation of new Monitor.

what:	Refresh didn't work
why:	Bytes swapped in handcrafted instruction in refresh code

what:	Refresh didn't work
why:	Relocation wrong in handcrafted instruction in refresh code

what:	Pup length wrong, checksum failures
why:	Compiler bug in evaluation of constant expressions (right associativity),

what:	Watchdog timer code didn't work
why:	Relocation wrong in Timer code (referencing clock locations)

what:	Power up reset fails, no way to test ROM code
why:	Bytes swapped in ROM fixups for first jump instruction, ROM fails

what:	ether transmit fails
why:	Initial stack in middle of code

what:	trash in code
why:	Refresh turned off for too long during initialization

what:	SLC transmitting at half speed (ROM only)
why:	SLC trying to fetch mode byte from code segment (in ROM)
	Only the CPU can read the ROM

Not counting the many screwups in file editting and ordinary bugs. . .

I made thirty versions of LarkMon.obj and nine versions of LarkMon.mb.

Lessons:
	This is an awfully good way to learn humility.
	Use a good assembler.
	Use an ICE system.

	-Larry
*start*
07679 00024 US 
Date: 21 FEB 83 20:46 PST
From: STEWART
Subject: VoiceProtocol Notes
To:   Stewart

Date: 9 Feb. 1983 9:18 am PST (Wednesday)
From: Stewart.PA
Subject: VoiceProtocol Notes
To: VoiceProject^.pa
cc: Stewart


Voice protocol connections fall into two categories, those between devices with identical clock frequencies and those between devices whose clock frequencies may be slightly different.  Lark-Lark connections are of the latter type because the Larks run from private crystals.  Lark-Bluejay connections are of the former type because the timing of Bluehay playback is established by the timing of Lark-to-Bluejay KeepAlive packets.

At issue is the extent to which the sequence numbers in arriving voice packets are to be believed.

Voice packets use the 32 bit Pup ID to hold two 16 bit sequence numbers.  The two sequence numbers are expPacket, which is incremented every time a packet is transmitted, be it voice or a KeepAlive, and expSample, which is incremented every packet time, whether or not that packet is actually transmitted.  ExpSample is therefore a clock which ticks on the grain of packets while expPacket is just a packet sequence number.

ExpPacket is easily disposed of.  The receiving station accepts the expPacket value in the first packet as gospel.  The value of expPacket in succeeding packets is only used to record statistics on missing or duplicate packets.

ExpSample is more difficult.  One should note that arriving packets need only be plunked down on a timeline according to their expSample numbers in order to reassemble the original voice.  Let us analyze two interesting cases:

Lark-Lark connection:

The crystals controlled clock frequencies of two Larks may differ slightly.  Since the crystal accuracies are 0.005% (are they?), the two frequencies may differ by one part in 10,000, or 0.8 sample times per second with 8 KHz sampling.  The connection starts with an anti-jitter delay of 10 milliseconds.  If the receiving Lark is running faster, the samples will be played out slightly faster than they arrive.  The 10 milliseconds (80 samples) worth of buffered voice will be slowly eaten up, running dry in no less than 100 seconds assuming zero actual jitter.  With jitter, the connection may break up sooner.  If the receiving Lark is slower than the transmitting Lark, the supply of buffered voice samples will slowly build up, making the perceived transmission delay longer and longer.

Larks correct for these effects by resynchronizing their clocks during silence intervals.  During talk spurts (runs of voice packets), the receiving Lark plays the samples in order, allowing the number buffered to build up or be drawn down according to the relative clock frequencies.  When a silence interval begins, the Lark plays the remaining stored samples and then begins to play silence.  At the end of the silence interval, a delay of exactly 10 milliseconds is inserted before the first sample of the new talk spurt is played.  If the receiving Lark is fast, the reproduced silent interval will be slightly longer in real time than the original.  If the receiving Lark is slow, the reproduced silent interval will be slightly shorter than the original.

In other words, a slow Lark takes longer to play out a given number of voice samples, so it makes the silence intervals slightly shorter to compensate.  A fast Lark plays out a given number of voice samples sooner than expected, so it makes the silence intervals slightly longer to compensate.

Lark-Bluejay conection:

Recording to Bluejay is no problem, Bluejay accepts the packets at whatever rate they come and puts them on the disk.

The native clock in Bluejay is likely to run a frequency slightly different from that of any specific Lark.  Rather than using the same technique as in Lark-Lark connections and carefully metering out the packets at its best guess at the correct rate, Bluejay depends on timing information fed back from the receiving Lark.

The overall effect is that a 1000 second piece (8,000,000 samples) recorded by a fast Lark and played back on a slow Lark will still consist of 8,000,000 samples, but will occupy 1000.1 seconds of real time.

A Lark receiving packets from Bluejay places each packet into the appropriate point in the time sequence according to the expSample number in the packet -- provided that the received sequence number is "sensible".

Here is what happens when everything works:

The very first packet from Bluejay is played after a 10 millisecond delay (for anti-jitter).

Sequentially numbered packets (expSample) are played out nose-to-tail.

The last packet of a talk spurt is assumed to have been played at the correct time.  During the silence interval, the Lark updates its private copy of expSample in units of the length of the last voice packet received.

The idea is to maintain the expected sample number during silent intervals so that at the end of the silent interval, the next talk spurt can be played at precisely the correct time.

This is done in the following way.  Lark maintains a variable called nextIndex, which marks the last point in the output ring buffer that has been filled with voice.  When a packet arrives in time and in order, it is placed in the buffer at nextIndex and then nextIndex is advanced and expSample is incremented.  When a packet fails to arrive before the sample at nextIndex has been played, Lark invents a packet full of silence and advances nextIndex and expSample.

Ideally, the first packet from Bluejay that marks the end of a silent interval will arrive at Lark slightly early, Lark will wait for its private copy of expSample to match the one in the packet, then place the packet in the ring buffer at nextIndex.

Things are not always ideal.  If a packet were to arrive containing an expSample value corresponding to the far future, it would be a mistake for Lark to wait for (potentially) minutes to play the packet.  If a packet were to arrive containing an expSample value corresponding to the past, Lark might sensibly discard it as being delayed, but if it happens consistantly, then Lark might discard all the packets.  For these reasons, Lark accepts only packets with expSample value corresponding to the immediate future (for a time corresponding roughly to the available buffering - 1/5 second).  If a packet arrives for a time outside this range, Lark resynchronizes itself by inserting a new 10 millisecond anti-jitter delay and by resetting its private copy of expSample.

Other notes:

ExpSample is a 16 bit number that counts packets, for normal 160 sample packets, expSample counts at 50 Hz and wraps around in 26 minutes.  (Wrap around is not injurious in any way, but Lark can only distinguish past from future withing a range of plus or minus 13 minutes.)

What happens if the packet size is different or if the packet size changes in the middle of a conversation?

In the Lark-Lark connection mode, the receiving Lark makes no judgements about packet sizes, it merely plunks down packets in the ring buffer and advances nextIndex according to the received packet size.

In the Lark-Bluejay conneciton mode, the receiving Lark must advance nextIndex even during silent intervals when no packets arrive.  Lark does this according to whatever packet size was last received.

At some point we might consider changing expSample to be a true sample sequence number.  If we count individual samples, expSample would wrap around in 8 seconds.  We could safely count, however, 8, 16, or 32 sample bunches, giving wraparound times of about one, two, or four minutes.  This would require that packets be a multiple of the bunch size.

*start*
09643 00024 US 
Date: 21 Feb. 1983 9:37 pm PST (Monday)
From: Stewart.PA
Subject: Voice Protocols
To: VoiceProject^.pa
Cc: Birrell, Boggs, Murray, Schroeder, Taft

Here are my current plans for Interactive and Voice File Server retrieval protocols.  Let me know how it looks.

These ideas have matured through discussions with Hal Murray, David Boggs, Severo Ornstein, and Dan Swinehart.

Glossary:
	Lark		The Etherphone
	Bluejay	The Voice File Server
	Thrush	The Etherphone Server

We need to allow the packets of a given voice connection to be encrypted with different keys on a packet to packet basis in order to allow Bluejay playback to be composed of different scraps of voice.  The Lark will keep a table of 16 encryption keys.  This table will be managed by Thrush.  We will add facilities to Lark.mesa (The Lark RPC command interface) to allow update and interrogation of the table.  (I favor sending the whole table each time.)  Encryption for voice protocol connections will be given in terms of indices into this table.

Interactive voice protocol:

This protocol will be used for Lark to Lark communication and for Lark to Bluejay communications (recording).

The principal requirement of this protocol is low delay.  It puts a relatively low priority on reliability.  Transmitting stations try to remember packets which have been sent recently, and will honor retransmission requests if they can.  Receiving Larks will never ask for retransmissions, because the data would arrive too late, but Bluejay may ask for retransmissions.

The transmitting Lark will gather up a packet of voice and fling it out.  Each packet will include:

Energy value
	1)   For another Lark to use for control of echo supression
	2)   For Bluejay to store for the convenience of prospective voice editors

Packet sequence number
	For collecting statistics on lost, duplicated, and misordered packets

Time-of-day
	Lark's real time clock with 1 millisecond resolution.  Since there are exactly 8 samples per millisecond this is really a sample sequence number.  (If someday some other sample rates are possible the distinction will be important.)

Packets sent
	Bit vector showing which packets in the recent past have not been transmitted (because they were silent).  This field is so that Bluejay will not ask for retransmission of non-existant packets.

Encryption key index
	Tells receiving Larks which key to use for decryption.  Requires that all participants in a multicast conference call use the same index.

A receiving Lark plays the first packet (or the first packet after a silent interval) after an anti-jitter delay of 10 milliseconds.  This delay permits variations in the arrival time of future packets to be covered and also permits slight variations in clock frequencies to be covered.

Aside on clock frequencies:

The crystal controlled clock frequencies of two Larks may differ slightly.  Since the crystal accuracies are 0.005%, the two frequencies may differ by one part in 10,000, or 0.8 sample times per second with 8 KHz sampling.  The connection starts with an anti-jitter delay of 10 milliseconds.  If the receiving Lark is running faster, the samples will be played out slightly faster than they arrive.  The 10 milliseconds (80 samples) worth of buffered voice will be slowly eaten up, running dry in no less than 100 seconds assuming zero actual jitter.  With jitter, the situation is worse.  If the receiving Lark is slower than the transmitting Lark, the supply of buffered voice samples will slowly build up, making the perceived transmission delay longer and longer.

Larks correct for these effects by resynchronizing their clocks during silence intervals.  During talk spurts (runs of voice packets), the receiving Lark plays the samples in order, allowing the number buffered to build up or be drawn down according to the relative clock frequencies.  When a silence interval begins, the Lark plays the remaining stored samples and then begins to play silence.  At the end of the silence interval, a delay of exactly 10 milliseconds is inserted before the first sample of the new talk spurt is played.  If the receiving Lark is fast, the reproduced silent interval will be slightly longer in real time than the original.  If the receiving Lark is slow, the reproduced silent interval will be slightly shorter than the original.

In other words, a slow Lark takes longer to play out a given number of voice samples, so it makes the silence intervals slightly shorter to compensate.  A fast Lark plays out a given number of voice samples sooner than expected, so it makes the silence intervals slightly longer to compensate.

A receiving Bluejay need not bother with anti-jitter delay, since the voice data is headed only for the disk.  All packets which arrive are put into proper time order according to their time stamp.  Bluejay may ask for retransmission of any packets which it thinks have been lost.  The retransmission request will contain a time-of-day (Lark clock value) and a bit vector requesting certain packets relative to that time.  We will make some judgement about how persistant Bluejay will be.

During silent intervals, Lark will send empty voice packets sufficiently often so that the silent packet bit vector will account for all packets.  Larks will ignore these nearly empty packets, but Bluejay will be interested.

Voice playback protocol:

This protocol is used for voice file playback from Bluejay to a Lark.

The principal requirements of this protocol are low initial delay, reliability, and control of timing by the receiving Lark.  To gauge these requirements I anticipate an initial delay of about 200 milliseconds and that Lark will never ask for the retransmission of a given packet more than once.

The basic idea is that an initial batch of packets will be sent by Bluejay and buffered by Lark. Lark will start to play them out, and Bluejay will thereafter transmit packets as needed to keep Larks buffers comfortably full.  This process will be controlled by Bluejay solicited feedback from Lark.

The protocol can handle playback intended for multicast reception, but only if one of the Larks is used to control transmission.

Lark-Bluejay packets are sent in response to requests from Bluejay and are sometimes sent autonomously.  They contain flow control and timing information for the use of Bluejay and may also contain retransmission requests from Lark.

Lark-Bluejay packets contain:

Lark Packet sequence number
	For collecting statistics

A Bluejay sequence number (fingerprint)
	Included if the packet is sent in response to a Bluejay request.  This number allows Bluejay to estimate the round trip delay.

A Lark clock value
	Allows Bluejay to adjust its packet transmission rate to the exact value needed to assure neither growth nor shrinkage of the amount of voice buffered in Lark.

A retransmission request
	A bit map that requests retransmission of certain packets relative to the Lark clock value.  A retransmission request will be made if a packet has not arrived, say, by 100 milliseconds before it is needed.  The bits in the vector refer to packets in the future, since retransmission of a late packet is moot.

Flow control, stating how far into the future packets can be accepted.  (This really informs Bluejay of the size of the buffer pool.

Bluejay to Lark packets contain:

Packet sequence number
	For collecting statistics and for fingerprinting Lark-Bluejay packets.

Probe
	A bit requesting that Lark send a Lark-Bluejay packet.

Time-to-play
	The packet is to be played at this time, according to the Lark's clock.  It is Bluejay's responsibility to send packets somewhat before they are needed.  as mentioned above, Lark may ask for a retransmission if a packet has not arrived.

Encryption key index
	Tells Lark what key to use to decrypt the packet.

Packets sent
	Bit vector showing which packets in the near future will not be transmitted (because they were silent).  This field is so that Lark will not ask for retransmission of non-existant packets.

Voice Data
	(possibly)

Scenario:

	This protocol is sufficiently complex that I present a scenario for its application.

Thrush will set up the socket numbers at both ends and will set up Lark's encryption key table.

Bluejay will initiate data flow by sending an empty packet to stimulate a Lark-Bluejay packet.  The reply will be used to aquire the current Lark clock and to estimate the round trip delay.  Bluejay will also learn how much buffering is available.

Bluejay will transmit the first buffer pool size worth of packets at fairly close intervals.  The Times-to-play will be set so that Lark's buffers will be full when the first packet is played.  This first batch of packets is sent faster than usual to cut down the initial delay before a playback gets rolling.  After the first batch Bluejay will transmit further packets at intervals calculated to keep the Lark buffers full.

Bluejay will send sufficient (empty) packets during silent intervals to reassure Lark that none have been lost.

Bluejay will occasionally send a packet with the probe bit set, requesting the current Lark situation.  The reply will be used to adjust Bluejay's clock to accurately correspond to Lark's.  (The adjustment will be both frequency, to account for native clock frequency differences, and phase, to account for varying transmission delays.)

Lark can spontaneously send a Lark-Bluejay packet to request retransmission of a lost packet which is due to be played in the near future.


Sometime after this is implemented and working, I'll write it down more formally.

	-Larry
*start*
01420 00024 US 
Date: 22 Feb. 1983 9:09 am PST (Tuesday)
From: Swinehart.PA
Subject: Re: Voice Protocols
In-reply-to: Stewart's message of 21 Feb. 1983 9:37 pm PST (Monday)
To: Stewart
cc: VoiceProject^, Birrell, Boggs, Murray, Schroeder, Taft

This protocol design is looking good.

A couple of comments:

It may not be necessary for Larks to buffer 200 ms. before beginning to play a
Bluejay tune.  I think an additional 200 ms. delay would add noticeably to
response time, although it would be acceptable.  Presumably Thrush will be able
to adjust this, at least crudely.

When the user wants to shut down an existing voice sequence quickly, the
buffering in the Lark may well be significant, depending on how large it gets
(200 ms. is possibly OK.)  We may need a way to tell the Lark to flush its
buffers too.  Sequencing this with similar commands to Bluejay could be tricky.

What prompted the switch to a Bluejay-initiated protocol?  It happened after the
last time we talked.  Apparently it allows Bluejay to have an estimate of the
lucky Lark's clock speed and the transmission delay before sending anything.

I need to understand more about what unlucky Larks will do (those that are not
clocking Bluejay.)  Also how in a multicast environment the lucky Lark will be
chosen and how we'll prevent other Larks from trying to act lucky.  I think I
can see a way through it, but I'm not absolutely sure.

*start*
00665 00024 US 
Date: 22 Feb. 1983 9:25 am PST (Tuesday)
From: Taft.PA
Subject: Re: Voice Protocols
In-reply-to: Stewart's message of 21 Feb. 1983 9:37 pm PST (Monday)
To: Stewart
cc: VoiceProject^, Birrell, Boggs, Murray, Schroeder, Taft

Sounds reasonable.

At some point you may want to make the amount of buffering and the anti-jitter delay adaptive rather than fixed, so that delay through gateways and such can be compensated for.

Does any provision need to be made in the protocol to help Thrush decide how busy the Ethernet is?

I presume that the calls which load encryption keys and such are themselves encrypted, using the RPC mechanisms.

	Ed

*start*
02187 00024 US 
Date: 22 Feb. 1983 12:34 pm PST (Tuesday)
From: Stewart.PA
Subject: Linking to EPROM routines
To: VoiceProject^.pa
cc: Stewart

Duval's linker has a facility called SYMBOLSONLY which should make it possible for code downloaded into the RAM to call separately linked and loaded monitor routines in the EPROM.

In a LINK command, one writes SYMBOLSONLY (or SO) in place of the INPUT construct.  THis produces a .rel file containing only relocation information.

(In fact, a dummy file must be added to the SO link command file to space the code and data segments so that they will lie at the correct addresses in the eventual system.

Consider the case of an EPROM exporting a code segment label Code1 and a Data segment (static) Data1.  Suppose that Code1 lies at address E060 and Data1 lies at DA20.

One might reference these items from RAM code in the following way:

extern Code1();
extern int Data1;

Data1 = Code1();

The rel file for this code must be linked with the rel file from the SYMBOLSONLY link in such a way that the RAM code references to the EPROM contain the correct addresses.

Ideally, one wants to SO link the EPROM code using a module SPACER containing the following:

C_CODE	SEGMENT
codesp	DB	0E000H DUP (?)
C_CODE	ENDS

C_DATA	SEGMENT
datasp	DB	0DA00H DUP (?)
C_DATA	ENDS

This will space out the EPROM code so that the labels are in the right places.  Unfortunately, when the link with the client code is done, the "spacing" is done relative to the segment start addresses for CODE and DATA.

This is not a real problem for code references, since the code for all of our RAM programs starts at 0400H.  (Thus the spacer needs to be 0E000H - 0400H)

However, the client data segment starts wherever the code ends, and this location is now known until locate time.

In order to link to EPROM statics therefore, a first link must be done using and value for datasp.  Then the actual address of the start of the data segment must be subtracted from the true address of the ROM statics (DA00 above) and the link run a second time.

It is possible that there is some magic with the loader that will make this odd two step unneccesary.

	-Larry

*start*
00334 00024 US 
Date: 23 Feb. 1983 9:49 am PST (Wednesday)
From: ornstein.PA
Subject: Briefing on Voice Project
To: Spencer, Taylor, Allen, Quinlan
cc: Swinehart, Stewart, ornstein

We are scheduled to get together on Monday, March 7 from 1:30 to 3:30 PM to
discuss the Voice Project. We will meet in the CSL Alcove.

Severo

*start*
02221 00024 US 
Date: 23 Feb. 1983 1:10 pm PST (Wednesday)
From: Taft.PA
Subject: Interval timer proposal
To: VoiceProject^, Fiala, Sturgis, Maxwell
cc: Taft

The voice file server requires an interval timer with higher resolution than the process timer used for Mesa condition variable timeouts.  The Spy requires interrupts at a higher rate also, and additionally would like wakeups uncorrelated with ticks of the process timer.

I propose the following simple low-level facility, to be implemented by microcode and heads.

IntervalTimerFace: DEFINITIONS =
  BEGIN

  ClockPulses: TYPE = LONG CARDINAL;
  -- This is what is returned by ProcessorFace.GetClockPulses and by
  -- the RCLK instruction.  Its resolution is defined by
  -- ProcessorFace.microsecondsPerHundredPulses.

  SetExpirationTime: PROCEDURE [time: ClockPulses];
  -- Sets the timer to expire at the specified time.  It is OK to call this
  -- while a Wait is already in progress.

  Wait: PROCEDURE;
  -- Waits until the time specified in the most recent SetExpirationTime
  -- has been reached.  Returns immediately if that time has already
  -- been reached.  Only one call to Wait should be in progress at a time.

  END.

This provides only a single timer.  The intent is that ordinary clients will not call this interface directly, but instead call a TimerMultiplexor package which maintains a priority queue of timeouts and condition variables and contains a single process which actually issues calls to SetExpirationTime and Wait.

What is required from the microcode is a way to cause a naked condition variable to be notified (i.e., an interrupt to occur) at a specified time.  For the Dorado, I intend to implement a MISC instruction which is passed the low 16 bits of the real time clock value at which the interrupt is to be generated.  The junk task (which wakes up at 32 microsecond intervals and increments the real time clock) will compare this value to the real time clock and generate the wakeup when the time is reached.

There is no requirement that the Dolphin and Dandelion implement it the same way.  In particular, the Dolphin has hardware timers which might be put to good use in implementing this.

Comments?

	Ed

*start*
00601 00024 US 
Date: 23 Feb. 1983 3:01 pm PST (Wednesday)
From: Swinehart.PA
Subject: Re: Interval timer proposal
In-reply-to: Taft's message of 23 Feb. 1983 1:10 pm PST (Wednesday)
To: Taft
cc: VoiceProject^, Fiala, Sturgis, Maxwell

Looks OK to me.  This should probably be run past Levin and/or whoever else is
responsible for orderly introduction of things into Cedar.  The multiplexor
package is something that ought to be available as soon as the Face is, so that
people don't write packages that bang into each other.  John Maxwell or one of
us are the likely candidates to write it.

*start*
00519 00024 US 
Date: 24 Feb. 1983 9:23 am PST (Thursday)
From: Fiala.PA
Subject: Re: Interval timer proposal
In-reply-to: Taft's message of 23 Feb. 1983 1:10 pm PST (Wednesday)
To: Taft
cc: VoiceProject^, Fiala, Sturgis, Maxwell

I have already implemented a direct handle on the Dolphin hardware timers
which is approximately the same as the feature you describe.  It is running in
the Trinity Pilot microcode as a special hack for one of the WRC people.  If
anyone has interest I can resurrect the details.

*start*
00414 00024 US 
Date: 24 Feb. 1983 6:33 pm PST (Thursday)
From: Taft.PA
Subject: IntervalTimerFace
To: VoiceProject^
cc: Schmidt, Maxwell, Taft

The next Dorado Cedar boot file Eric builds will contain an implementation of IntervalTimerFace.  IntervalTimerFace.bcd and .mesa are now available via [Indigo]<PreCedar>Top>PilotInterfaces.df.

Dolphin and Dandelion have dummy implementations at present.
	Ed

*start*
01307 00024 US 
Date: 28 Feb. 1983 12:18 am PST (Monday)
From: Clark.PA
Subject: On contemplating Severo Ornstein contemplating Karen Kolling
 contemplating Swinehart's desk.
To: CSL^, VoiceProject^
Reply-To: Clark.pa

A telephone that's really keen,
let it be pink or blue or green,
is one that chops your voice to bits
and sends it where sound's never been.

Send no verbal intonation,
with analog excitation;
thru the ether course these bits,
packets filled with information.

The sound that's changed to zero or one
is known by if there's volts or none.
Tranceivers push along the bits;
computers make the whole thing run.

Held for a blink in memory;
if charged or not, still binary.
It's hard to tell if growl or song
with bits of voice stored virtually.

Program control here is the mode.
Thru ALU on eight lane road;
the voice in bits now parallel
moves to the beat of microcode.

Remembered tones becomes a choice;
talk stored on disks, let all rejoice.
Whether or not its magnetized
is disk code for binary voice.

On to callee, extremely fast;
you cannot see the bits go past
on ethernet to color phones.
The torn up voice is now recast.

The bits are changed, for your ears suited,
like fruit juice reconstituted;
digital to analog,
out comes your voice not even muted.

				Larry Clark
*start*
01002 00024 US 
Date: 25 Feb. 1983 1:56 pm PST (Friday)
From: Stewart.PA
Subject: capricious computer
To: VoiceProject^
cc: Thacker, Orr, DBrown, Taft, Boggs, Murray

Notes from Rockwell Collins in a Packet Radio Weekly Report:

1.  Our TAC was revived late Thursday and we are operational again, with
    the exception of not being able to turn on flow control for the Diablo
    (a continuing inconvenience since the change to a TAC and its port
    default arrangement).  We had been without our TAC since last Friday
    morning, when the serviceman replaced three fans (how does replacing
    fans cause a computer to fail? - Its an old, capricious computer).  We
    have two more fans to replace, but we could not afford another week.  We
    managed to read mail via phone/modem, but responses had to wait for the
    TACs resurrection.  The length of time required to repair the Honeywell
    316 TAC is indicative of the need to have them replaced by C-30s as soon
    as possible.


*start*
03521 00024 US 
Date: 8 March 1983 1:39 pm PST (Tuesday)
From: Ousterhout.PA
Subject: Re: Voice Protocols
In-reply-to: Stewart's message of 21 Feb. 1983 9:37 pm PST (Monday)
To: Stewart
cc: VoiceProject^

I've started thinking about how to implement your new proposal for
Lark-Bluejay voice transmission.  Although I like the overall plan,
I've come across several things that appear to cause trouble.  The
troubles arise because of interactions between real time, packet sequence
numbers, and silence suppression.

I think we better legislate that all packets will be exactly the same size,
e.g. 160 bytes, and that all packets will be aligned in real time on 160
byte boundaries.  This is to solve several problems:

Problem #1: How does time-of-day map onto packet sequence numbers?
For example, it's not clear to me how to interpret the "packets sent"
bit map.  For that matter, why is "packets sent" even needed?  Since
packet sequence number are strictly sequential, either party can detect
a lost packet by a skip in the packet sequence number.  When Bluejay
sends Lark a bit vector telling which packets in the near future will
not be transmitted because they are silent, how does Lark know how
much time this corresponds to?

Problem #2:  How does Bluejay handle silent packets?  When a whole
second of silence occurs, Bluejay stores a null chirp pointer and never
writes the voice to disk.  However, if there is a partial second of silence,
something has to get stored to pad out the partially-used chirp.  Right
now Bluejay stores zeroes.  On playback, if the first few bytes of a packet
are zeroes, Bluejay assumes the whole packet is silent and doesn't send
it.  However, this only works if packets are all the same size, or at least
get played out with the same packet structure as they were recorded.
Otherwise, the zeroes might start or end in the middle of a playback
packet.  In the first case, zeroes will be sent to Lark (causing a horrible
squawking when they are "decrypted" and then played).  In the second
case some valid speech will be lost when Bluejay decides the packet is
silent and discards it.  Representing silence as zeroes is kludgy at best,
since it's possible that valid data could encrypt to zeroes, isn't it?

If we legislate that all packets are exactly 160 samples which is exactly
20 ms of Lark real time, then several simplifications can occur.  We can
represent time-of-day in units of 20ms, and packet bit-maps map easily
into time-of-day.  I'll change Bluejay to store voice in packetized chunks,
which will allow me to store flags (such as "silent") with each packet and
thereby handle playback in a more intelligent fashion.

If we decide to permit variable-size packets, then things are tougher.
Packet bit maps won't work very well in this case (but then I'm not sure
they are a good idea even with fixed-size packets).   As for handling
silence in Bluejay, I can only see 2 alternatives:  a) force Bluejay to
examine every byte of each packet to find all the silent areas, and hope
that valid data won't ever encrypt to zeroes;  or b) have somebody
(perhaps a Lark?) supply Bluejay with the correct encrypted value of
zero to use for each recording, so that everything stored in the jukebox
can be played back without causing squawking.  Could alternative (b)
introduce a security loophole if some evil party intercepts the special
encrypted zero packets?

I think we can make things a lot simpler all around if we fix the
packet size.  How awful would this be?