[prey] installing prey
Peter Borgmann
piborg at gmail.com
Sat Dec 13 08:40:44 EST 2008
Ryan C. Gordon schrieb:
>
>> derivate based on Elyssa if that matters. Just a wild guess: perhaps
>> dsp can be considered the lowest common denominator, since /dev/dsp
>> should be present on all (or most at least) Linux systems?
>
> It tends to be present, but lots of times, it's a fake thing, like a
> wrapper script that catches open() calls to /dev/dsp and pipes them to
> something else, like PulseAudio or ALSA...and usually poorly. Even
> ALSA's in-kernel /dev/dsp emulation can produce bad results where
> talking to the same hardware directly through ALSA works...which is
> somewhat baffling to me. More baffling: sometimes talking to the
> /dev/dsp emulation works better than talking to the hardware through
> ALSA.
>
> [...]
> --ryan.
I don't know much about these things, but strange things happen indeed.
A pulseaudio daemon seems running on my system:
pi at Serenity ~ $ ps aux | grep pulseaudio
pi 6087 0.0 0.2 28364 5708 ? Sl 13:44 0:02
/usr/bin/pulseaudio --log-target=syslog
pi 6192 0.0 0.1 5676 2212 ? S 13:44 0:00
/usr/lib/pulseaudio/pulse/gconf-helper
but explicitly using pulseaudio with prey by setting SDL_AUDIODRIVER
completely deactivates sound in prey. In a next step I found a
configuration site from Arch Linux, dealing with pulseaudio and followed
these steps. No difference, but SDL_AUDIODRIVER=alsa or dsp both still
works.
So what you say don't really explain to me why the sound stutters in
prey w/o setting this variable. On the other hand my system never ran
into sound problems, prey seems one of the extremely rare exceptions. So
to me it looks like it is you who does some non-conform things with
sound implementation.
greets,
Peter
More information about the prey
mailing list