6 Jan
2025
6 Jan
'25
9:20 p.m.
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.
6 Jan
6 Jan
9:51 p.m.
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
10 Jan
10 Jan
10:05 p.m.
P.S.:
Steffen Nurpmeso wrote in
<20250106215143.b3Q14AL1(a)steffen%sdaoden.eu>:
|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*![.]
For the younger and overall clarification.
Around Y2K many programs -- audio players, but also early desktop
environment "betas" of GNOME and KDE unless my memory fools me
completely (i used such by then, at least at times, when not under
FreeBSD cons25 or Linux then framebuffer!) -- had fixed paths
built-in, for example /dev/dsp or /dev/pcm or /dev/audio or
whatever it actually was (for real). There may have been multiple
dev files, actually, ie, /dev/dsp1/2/3 etc, but the path was
built-in, and it would not multiplex: if you opened /dev/dsp1 you
had /dev/dsp1, but /dev/dsp and that thing was in use, and could
not be used for any other purpose, at all.
With the FreeBSD change program 1 could open "/dev/dsp", but
2 could open it, too, because it internally multiplexed to the
virtual .1 .2 .3 etc. This was a tremendous improvement!
--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
15 Jan
15 Jan
7:40 a.m.
On Mon, Jan 6, 2025 at 2:21 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
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?
You might be synthesizing a bit of serendipity that wasn't there in
the moment in both directions: what switches were and where multimedia
wasn't yet. The 5ESS is primarily concerned with time/space/time
switching, that those slots are PCM audio, signalling, or data is not
so important beyond getting it to the right place on time. To
potentially highlight the distinction, you need a seperate machine
(potentially many) called an announcement system, to produce what
you'd assume to be intrinsic and familiar audio necessary for end user
telephony on a 5E. So it is not so great at much related to computer
audio unless you consider line interface units really expensive
ADC/DAC. And that is the domain of microcontrollers far away from
UNIX. It might live on completely separate machines like channel
banks or SLC systems. So the BORSCHT part of getting analog audio in
and out predates all this and maybe PCM _is_ the great achievement for
computer audio, because regardless of how the audio is produced or
encoded it probably lives as PCM at your DAC.
I will speculate that the AT&T folks didn't yet have pressing need for
UNIX to have rich multimedia capabilities so they just weren't in the
position to define lasting APIs - you can find historical research
systems of the IBM mainframe and DEC variety where people were
figuring out things like music and speech synthesis at Bell and
elsewhere. But for Big Telecom, think more like TI's Speak&Spell...
microcontroller, PCM ROM, DAC.. That's the way electronic phone
systems were designed when it came time to produce audio, as
distributed systems of microcontrollers or DSPs and fixed function
ASICs, with as little involvement from anything resembling a full OS
as possible. It wasn't until the 1990s that Computer Telephony (CT)
really took off, with vendors like Dialogic, or later on software like
Asterisk. That was maybe concurrent to the Multimedia PC of the early
1990s where the desire went beyond games synthesis or commanding a
CD/LaserDisc's PCM to storing, processing, and playback of media files
-- now you need audio APIs -- and AT&T is no longer in the driver's
seat. OSS is pretty good, and was in there by the time Univel took
the helm of UNIX where they thought so too so it might be as close to
official as one can get. Audio is one of those areas where Linux
earns the facepalm.
Cheers,
- Matt G.
27
days inactive
36
days old
3 comments
3 participants
participants (3)
-
Kevin Bowling -
segaloco -
Steffen Nurpmeso