if user in audio group, padsp not work correctly?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lennart Poettering <lennart at poettering.net> ha escrito:

> PA doesn't check for the 'audio' group. Are you sure that this change
> of behaviour is related to the 'audio' group. Try setting $PULSE_LOG
> to 99 and $PADSP_DEBUG to 1 to figure out what is going on.
>
> Lennart
>


Hello.

True, padsp doesn't check for the 'audio' group., but the program  
jclic for example, check if the user belongs to the group 'audio' and  
tries to connect through OSS devices mapping from ALSA, instead of  
/dev/dsp directly.

Log:
utils/padsp.c: open(/dev/snd/controlC0)
utils/padsp.c: open(/dev/snd/pcmC0D0p)
utils/padsp.c: open(/dev/snd/controlC0)
utils/padsp.c: open(/dev/snd/controlC0)
utils/padsp.c: open(/dev/snd/pcmC0D0c)
utils/padsp.c: open(/dev/snd/controlC0)
utils/padsp.c: open(/dev/snd/controlC0)
utils/padsp.c: open(/dev/snd/pcmC0D1p)

Browsing ALSA configuration (ALSA-Configuration.txt) in the  
alsa-source, I found that there are two ways of getting an application  
to work with ALSA if the application was written for OSS, the first  
way is to allow the application open /dev/dsp* and the second way is  
try to access native ALSA device files such as /dev/snd/pcmC*

ALSA PCM devices to OSS devices mapping
=======================================

/dev/snd/pcmC0D0[c|p]  -> /dev/audio0 (/dev/audio) -> minor 4
/dev/snd/pcmC0D0[c|p]  -> /dev/dsp0 (/dev/dsp)     -> minor 3
/dev/snd/pcmC0D1[c|p]  -> /dev/adsp0 (/dev/adsp)   -> minor 12
/dev/snd/pcmC1D0[c|p]  -> /dev/audio1              -> minor 4+16 = 20
/dev/snd/pcmC1D0[c|p]  -> /dev/dsp1                -> minor 3+16 = 19
/dev/snd/pcmC1D1[c|p]  -> /dev/adsp1               -> minor 12+16 = 28
/dev/snd/pcmC2D0[c|p]  -> /dev/audio2              -> minor 4+32 = 36
/dev/snd/pcmC2D0[c|p]  -> /dev/dsp2                -> minor 3+32 = 39
/dev/snd/pcmC2D1[c|p]  -> /dev/adsp2               -> minor 12+32 = 44


To force the application to open /dev/dsp by default, also to the PA  
server specified in $PULSE_SERVER, I added a extra checking to  
'src/utils/padsp.c':

  static int real_open(const char *filename, int flags, mode_t mode) {
      int r, _errno = 0;
+    char *env_d;

      debug(DEBUG_LEVEL_VERBOSE, __FILE__": open(%s)\n",  
filename?filename:"NULL");

+    env_d = getenv("DISPLAY");
+    if (!env_d) {
+        return _errno;
+    }
+    else if (strcmp(env_d, ":0.0") != 0) {
+       if (strstr(filename, "/dev/snd/pcmC") != NULL) {
+         function_exit();
+         return _errno;
+       }
+    }
+

I have used '$DISPLAY' to differentiate thin clients of regular  
clients, but I suppose that just checking if a program tries playback  
through OSS devices mapping '/dev/snd /pcmC*' should be sufficient and  
of course the hack can be improved.

Regards




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux