Em 16-06-2011 12:11, Hans de Goede escreveu: >>> I've also changed the default -alsa-pb value to "default" as we should >>> not be picking something else then the user / distro configured defaults >>> for output IMHO. The user can set a generic default in alsarc, and override >>> that on the cmdline if he/she wants, but unless overridden on the cmdline >>> we should respect the users generic default as specified in his >>> alsarc. >> >> While pulseaudio refuses to work via ssh, this is actually a very bad idea. >> Xawtv is used by developers to test their stuff, and they generally do it >> on a remote machine, with the console captured via tty port, in order to >> be able to catch panic messages. >> > > I'm sure developers are quite capable of creating either an .alsarc, pass > the cmdline option, or change pulseaudio's config to accept non local console > connections.
As far as I noticed, most media developers seems to not be comfortable with pulseaudio. Using pulseaudio by default would require more experience from developers, otherwise nobody will be able to properly support it. For example, the only way I know that works to remove an audio module used by pulseaudio is by doing dirty tricks like: while : ; do kill pulseaudio; rmmod <audio_module> && break; done I was told that there's a pactl syntax, but I was never able to find how to make it work, not even on a local console (and I need it supported via ssh). >From other posts, other developers at this ML also didn't discover how to do it yet. A pulseaudio or .alsarc config to enable ssh would be fine, but, again, that's not obvious. While developers are not comfortable with pulseaudio, turning it into a default is a bad idea. > > We should try to have sane user oriented defaults, not developer oriented > defaults. > > Also not all developers work the same way you do, so having a certain default > just so it matches your work flow also is a bad idea IMHO. > >> For now, please revert this patch. After having pulseaudio fixed to properly >> handle the audio group, I'm ok to re-add it. >> >>> We could consider making the desired latency configurable, currently >>> I've hardcoded it to 30 ms (was 38 with the old code on my system) note >>> that I've chosen to specify the latency in ms rather then in a number >>> of samples, since it should be samplerate independent IMO. >> >> Yeah, having latency configurable sounds a good idea to me. > > Done. Thanks! Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
