[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