Em 12-06-2011 10:57, Devin Heitmueller escreveu: > On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: >> BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds >> the device nodes open, pinning the cx18-alsa and cx18 modules in kernel. >> When killed, PulseAudio respawns rapidly and reopens the nodes. >> Unloading cx18 for development purposes is a real pain when the >> cx18-alsa module exists. > > We've talked about this before, but something just feels wrong about > this. I don't have this problem with other drivers that provide an > "-alsa" module. For example, my ngene tree has four ALSA PCM devices > and 16 mixer controls, yet PulseAudio doesn't keep the module in use. > > The more I think about this, the more I suspect this is just some sort > of subtle bug in the cx18 ALSA driver where some resource is not being > freed. It is not just cx18 that have this trouble. All drivers under media/video with *-alsa have this issue. Also, all sound drivers suffer from the same issue: # lsmod|grep snd_hda snd_hda_codec_analog 84955 1 snd_hda_intel 25261 2 See: pulseaudio keep the device opened, so dev refcount were incremented. # rmmod snd_hda_codec_analog snd_hda_intel ERROR: Module snd_hda_codec_analog is in use ERROR: Module snd_hda_intel is in use The same happens, for example, with em28xx with snd-usb-audio: # lsmod |grep snd snd_usb_audio 91303 1 # rmmod snd-usb-audio ERROR: Module snd_usb_audio is in use What happens is that open() increments the device refcount. Maybe the ngene has some trick for allowing it, or PulseAudio has some logic to detect ngene (or otherwise it fails to open ngene audio nodes). It may have some dirty ways to trick PulseAudio, for example returning -ENODEV if the process name is pulseaudio, but I can't think on a proper kernel solution for it. The proper solution is to fix PulseAudio. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
