The sound situation in the UNIX world to me has always felt particularly
fragmentary, with OSS offering some glimmer of hope but faltering under the long
shadow of ALSA, with a hodge podge of PCM and other low level interfaces
littered about other offerings.
Given AT&T's involvement with the development of just about everything
"sound over wires" for decades by the time UNIX comes along, one would suspect
AT&T would be quite invested in standardizing interfaces for computers
interacting with audio signals on copper wire. Indeed much of the ESS R&D was
taking in analog telephone signals, digitizing them, and then acting on those
digitized results before converting back to analog to send to the other end.
Where this has me curious is if there were any efforts in Bell Labs, prior to
other industry players having their hands on the steering wheel, to establish an
abstract UNIX interface pattern for interacting with streams of converted audio
signal. Of course modern formats didn't exist, but the general idea of PCM was
well established, concepts like sampling rates, bit depths, etc. could be used
in calculations to interpret and manipulate digitized audio streams.
Any recollections? Was the landscape of signal processing solutions just so
particular that trying to create a centralized interface didn't make sense at
the time? Or was it a simple matter of priorities, with things like language
development and system design taking center stage, leaving a dearth of resources
to direct towards these sorts of matters? Was there ever a chance of seeing,
say, the 5ESS handling of PCM, extended out to non-switching applications, or
was that stuff firmly siloed over in the switching groups, having no influence
on signal processing outside?
- Matt G.
I mentioned a few weeks ago that I was writing this invited paper for an
upcoming 50-year anniversary of the first issue of IEEE Transactions on
Software Engineering.
The paper has now been accepted for publication and here's a preprint
version of it:
https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf
Marc
> Was the landscape of signal processing solutions just so
> particular that trying to create a centralized interface didn't make
sense at
> the time? Or was it a simple matter of priorities, with things like
language
> development and system design taking center stage, leaving a dearth of
resources
> to direct towards these sorts of matters? Was there ever a chance of
seeing,
> say, the 5ESS handling of PCM, extended out to non-switching
applications,
In the early days of Unix there were intimate ties between CS Research and
Visual and Acoustic Research. V&A were Bell Labs' pioneer minicomputer
users because they needed interactive access to graphics and audio, which
would have been prohibitively expensive on the Labs' pre-timesharing
mainframes. Also they generally had EE backgrounds, so were comfortable
working hands-on with hardware, whereas CS had been largely spun off from
the math department.
Ed David, who led Bell Labs into Multics, without which Unix might not have
happened, had transferred from V&A to CS. So had Vic Vyssotsky and Elliot
Pinson (Dennis's department head and coauthor with me of the introduction
to the 1978 BSTJ Unix issue). John Kelly, a brilliant transferee who died
all too young pre-Unix, had collaborated with Vic on BLODI, the first
dataflow language, which took digital signal processing off breadboards and
into computers. One central member of the Unix lab, Lee McMahon, never left
V&A.
The PDP-7 of Unix v0 was a hand-me-down from Pinson's time in V&A. And the
PDP-11 of v1 was supported by a year-end fund surplus from there.
People came from V&A to CS because their interests had drifted from signal
processing to computing per se. With hindsight, one can see that CS
recruiting--even when it drew on engineering or physics
talent--concentrated on similarly motivated people. There was dabbling in
acoustics, such as my "speak" text-to-speech program. And there were
workers dedicated to a few specialties, such as Henry Baird in optical
character recognition. But unlike text processing, say, these fields never
reached a critical mass of support that might have stimulated a wider array
of I/O drivers or full toolkits to use them.
Meanwhile, in V&A Research linguists adopted Unix, but most others
continued to roll their own one-off platforms. It's interesting to
speculate whether the lack of audio interfaces in Unix was a cause or a
result of this do-it-yourself impulse.
Doug

In the lost-in-time department, my group at Digital Cambridge Research lab in 1993 did an audio interface patterned after the X Window system. Paper in the Summer USENIX: https://www.usenix.org/legacy/publications/library/proceedings/cinci93/gett…
For extra fun, the lab director of CRL at the time was Vic Vyssotsky.
But there must have been some Bell work, because around 1983 (?) when I was doing Etherphone at PARC I visited John DeTreville at Holmdel. He was building a voice - over - Ethernet system as well.
-Larry
> On Jan 6, 2025, at 4:51 PM, Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote:
> segaloco via TUHS wrote in
> <BWYwXjScYdFHM1NV0KEtgvazEfJM1PX7WaZ8lygZ45Bw2pEQG6JQr5OCtX-KMwEwr_k2zLD\
> GXac7wymRCtifnU9VKnlsrJCrKFqGZSgM6-0=(a)protonmail.com>:
> |The sound situation in the UNIX world to me has always felt particularly
> |fragmentary, with OSS offering some glimmer of hope but faltering under \
> |the long
> |shadow of ALSA, with a hodge podge of PCM and other low level interfaces
> |littered about other offerings.
>
> Oh, but *how* great it was when FreeBSD came on over with those
> "virtual sound devices", in 4.7 or 4.9 i think it was. Ie instead
> of one blocking device, one could open dev.1 and dev.2 and it was
> multiplexed in the kernel. It did some format conversion in the
> kernel alongside this.
>
> It was *fantastic*!, and i had a recording program sitting on
> a Cyrix 166+ and it took me ~1.5 percent of (single) CPU to record
> our then still great Hessenradio HR3 for long hours (Clubnight
> with worldwide known DJs, Chill with great sets in the Sunday
> mornings), and oh yes HR2 with the wonderful Mr. Paul Bartholomäi
> in "Notenschlüssel" (classical music), and the fantastic "Voyager"
> hour with Robert Lug on Sunday evening. It cannot be any better.
> I could code and compile and there was no stuttering alongside.
> 1.5 percent of CPU, honestly!
>
> I say this because FreeBSD has replaced that very code last year,
> if i recall correctly. It now all scales dynmically, if i read
> the patches that flew by right. (So it may be even better as of
> now, but by then, over twenty years ago, it blew my mind. And the
> solution was so simple, you know. The number of concurrent
> devices was a compile time constant if i recall correctly, four by
> default.)
>
> I also say this because today i am lucky i can use ALSA on Linux,
> and apulse for the firefox i have to use (and do use, too
> .. i also browse the internet in such a monster, and at least in
> parts still like that). I always hated those server solutions,
> where those masses of audio data flow through several context
> switches. What for? I never understood. Someone convinced me to
> try that pulseaudio server, but i think it was about 20 percent of
> CPU for a simple stream, with a terrible GUI, and that on
> a i5-8250U CPU @ 1.60GHz with up to 3.4 Ghz (four core; the four
> HT are alwys disabled). 20 percent!!
>
> ...
> |Any recollections?[.]
>
> Sorry, the above is totally apart, but for me the above is still
> such a tremendous thing that someone did; and for free. Whoever
> it was (i actually never tried to check it, now that i track their
> git for so many years), *thank you*!
> (And that includes the simple usual format conversions in between
> those 22050/44100 etc etc. Just like that -- open a device and
> read it, no thousands of callbacks, nothing. And 1.5 percent CPU.
> Maybe it is not good/exact enough for studio level audio editing.
> But i still have lots of those recordings, except that the "Balkan
> piss box" chill somehow disappeared. (Sorry Pedja, shall you read
> this.))
>
> --steffen
> |
> |Der Kragenbaer, The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
> |
> |In Fall and Winter, feel "The Dropbear Bard"s pint(er).
> |
> |The banded bear
> |without a care,
> |Banged on himself for e'er and e'er
> |
> |Farewell, dear collar bear
Do I remember correctly that the early linux exec as a userland exec?
I think this came up before, I just can't recall.
I just learned about:
https://github.com/hardenedlinux/userland-exec
Hi.
The paper on compressing the dictionary was interesting. In the day
of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is
a big savings.
Was the compressed dictionary put into use? I could imaging that
spell(1) at least would have needed some library routines to return
a stream of words from it.
Just wondering. Thanks,
Arnold
I am curious about the apposite Bergson quote (intelligence...tools) found
at the beginning of the Forward mentioned in the subject. Specifically, I am
wondering if the quote was originally discovered in _Creative Evolution_
as a part of a course or through private reading.
I am interested in the diffusion of Continental ideas concerning technology
in English speaking countries during the 20th Century.
Dr Rick Hayes
durtal(a)sdf.org SDF Public
Access UNIX System - https://sdf.org
All, Yufeng Gao has done more amazing work at extracting binaries,
source code and text documents from the DECtapes that Dennis Ritchie
provided for the Unix Archive:
https://www.tuhs.org/Archive/Applications/Dennis_Tapes/
His latest e-mail is below. I've temporarily placed his attachments here:
https://minnie.tuhs.org/wktcloud/index.php/s/aWkck2Ljay6c5sB
He needs some help with formatting old *roff documents. If someone could offer
him help, that would be great. His e-mail address is yufeng.gao AT uq.edu.au
Cheers, Warren
----- Forwarded message from Yufeng Gao -----
Date: Tue, 31 Dec 2024
Subject: RE: UNIX DECtapes from dmr
Hi Warren,
Happy New Year! Here's another update. I found more UNIX bins on
another tape ('ken-sky'). They appear to be between V3 and V4. I have
attached them as "ken_sky_bins.tar". I have also attached an updated
tarball of the V2/V3 bins recovered from the 'e-pi' tape (with a few
names corrected), see "identified_v2v3_bins_r2.tar".
So far, the rough timeline of UNIX binaries (RTM hereinafter refers to
the exact version of the OS described by the preserved manuals) is as
follows:
Sys: V1 RTM <= unix-study-src < s1/s2 < V2 RTM < V3 RTM < nsys < V4 RTM
Bin: V1 RTM < s1/s2 < epi-V2 < epi-V3 < ken-sky-bins < V4 RTM
There is a possibility that the V2 bins from the 'e-pi' tape belong to
V2 RTM, as they're all PDP-11/20 bins with V2 headers. In contrast,
most of the bins from the s1/s2 tapes are V1 bins. Some of them are
identical to those from the 's2' tape, and if the timestamps from the
's2' tape can be trusted, they're from May/June 1972.
The V3 bins from the 'e-pi' tape are most likely from late 1972 or
early 1973, but no later than Feb 1973, as they've been overwritten by
files from Feb 1973. This suggests they're from a V3 beta, supported by
the fact that some features described in the V3 manual are missing. The
files were laid out in perfect alphabetical order on the tape.
The bins from the 'ken-sky' tape fall somewhere between V3 RTM and V4
RTM. The directory structure and other elements match the V3 manual, as
do the syscalls (e.g., the arguments for kill(2) differ between V3 and
V4, and these bins use the V3 arguments). The features, however, are
closer to V4. For example, nm(1) had already been rewritten in C and
matches the V4 manual's description. The assembler also matches the V4
manual in terms of the number of temp files, and the C compiler refers
to the assembler as 'nas.' The assembler is located physically between
files starting with "n" and "o," and the files around it follow a weak
alphabetical order, so it is logical to assume that it was named "nas".
It is a bit difficult to version these binaries, especially without any
timestamps. The lines between versions for early UNIX are blurry, and
modern software versioning terms like "beta" and "RTM" don't really
apply well. If these binaries are to be preserved (which I hope they
will be, even though the kernels are long gone), I'd put the V2 bins
from 'e-pi' under V2, the V3 bins from 'e-pi' under V3, and the bins
from 'ken-sky' under V4 (I'd argue that nsys also falls under V4, as
the biggest change between V3 and V4 was the kernel being rewritten in C).
There are other overwritten files on the tapes, and I will address them
later. There are quite a few patents, papers, and memos in *roff
format, but I'm not entirely sure what to do with them. Among those, I
have picked out some V4 distribution documents and attached them as a
ZIP folder :-). If you know of ways to generate PDFs from these ancient
*roff files accurately, please lend a hand - I'm struggling to get
accurate results from groff.
Sincerely,
Yufeng
----- End forwarded message -----
