Joel Roth writes:
> Hi Martin,
> Pulse audio requires D-Bus, and D-Bus is the underlying RPC
> mechanism of a large and controversial software stack
> developed to support desktop applications.
Thank you for this good and quick explanation.
>
> Apparently pulseaudio is unable to get D-Bus services,
> due to a dependency of the latter on X.
>
> So you need either to satisfy/finesse this dependency of
> D-Bus, or disable/remove pulseaudio. I've read but not
> tested apulse, a library that purports to presents a pulse
> audio API to applications such as skype that require them,
> relaying the audio to ALSA.
It looks like pulseaudio has been the ghost in the
basement on my system for about ten years.
For now, I took it off completely and killed the
process. Before the CS4236 went away, there was always a sound
device for Card 0 and, if I had a second sound card, there was
another sound device for the second card. It was typical to see
/dev/dsp linked to Card 0, an actual /dev/dsp0 device and
/dev/dsp1 for Card 1 and so on. Just for fun, I think I stuck in a
USB sound card in addition to cards 0 and 1 and predictably got
/dev/dsp2 plus a lot of strange audio that sounded like a bad
tape transport due to all the sound cards trying to write to
their little segments of memory at the same time on a 600-MHZ
Pentium.
Back to the present, I still had PA (pulseaudio)
running, no official Card 0 and a USB-based Soundblaster Digi
acting as Card 1. At least that's what aplay -l said.
I could run mplayer and the playback was excellent but
amixer for Card 0 only showed one control for left and right
front volume.
After I killed PA, mplayer said it couldn't find any
cards as there was no /dev/dsp any more. I did however find
/dev/dsp1 for the SBdigi so I manually forced a link with ln -s
to link /dev/dsp to /dev/dsp1. Presto! mplayer was happy again
and played music and other audio files but the story isn't quite
over yet. I'm thinking that pulseaudio does some signal
processing, also. Some of the sound files I listen to are 8-bit
PCM voice recordings made at 8000 samples per second. They're
just fine for recording two-way radio chatter. Mr. Nyquist is
happy because 3 to 4 KHZ is the highest frequency you will
usually hear over such communication so it doesn't sound much
different than it did when first heard over the air.
Before I killed PA, the audio of those raw PCM
recordings sounded fairly normal. After I killed PA, you can now
still hear the audio but you can also hear the 8-KHZ sampling
which sounds like a cheap toy as most of those don't bother with
a low-pass filter but let your ears and brain do that.
It is possible that pulseaudio is using DSP techniques
to shape the wave forms properly and then is up-converting the
samples that the sound card sees. You can't add any fidelity
that is not already there, but this would act as a very good
low-pass filter.
I also got in to /etc/modprobe.d and added a line to
alsa-base.conf to make the SBDigi be card 0 until I can resurrect the CS4236 and
this seems to have made everything work automatically again.
amixer now reports a full-featured sound card with all the
controls one needs to do good playback and normal recording. The
playback is actually better than the CS4236 was so now we have
some progress. After things settle down, I may put PA back just
for the signal processing but for now, it's best to keep things
as simple as possible.
Again, thanks for the explanation of some of
pulseaudio's purpose in life. It is presently used in those
screen reader modules that allow the kernel to generate
synthesized speech so it isn't all bad but it sure helps to know
what it does.
Martin McCormick
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150716111542.77fb622...@server1.shellworld.net
