On Tue, 18 Oct 2011 15:05:31 +0200, Micha? Sawicz <michal at sawicz.net> wrote: >> The "volume control" tool would have two problems: >> - It only works after the record stream is started, so that the source >> output exists. For recording purpose, you'd want to select the source >> before you start the recording. > Not true. If you select the fallback recording stream before you start > recording, that's what VLC will get as the source. Also, if you select a > source for VLC, it will "stick" thanks to module-*-restore, so after > setting it once, you'll get that until you change it again. Or other > things happen, like external headsets connected and stuff. There was a > lengthy post about routing (and its future) from Colin Guthrie, but I > can't find it now... Interwebs, help, please? Restoring assumes that one application always want the same source/sink. If the application has only one profile, that's just fine. Precisely my problem is, VLC captures different things. And there is no application other than VLC itself to take care of them: * camera (V4L2): Audio should come from the microphone unless otherwise stated. * screen (X11): Audio should come from the monitor of the default-or-whatever sink unless otherwise stated. * analog TV (V4L2 with frequency tuning): Audio _must_ come from the ALSA card matching the V4L2 device node. * digital TV (DVB): Audio is (de)muxed. While restoring makes sense for each of the first two profile, it does not make much sense (IMHO) across them. And the audio input of the ATV profile should definitely not be saved, then restored in the camera or screen profile. >> - It has poor usability. The user would have to configure the >> application, >> including all parameters except the audio source and amplification. For >> those, it would have to open a separate application. > Depends on the definition of usability. Having different dialogs in > every single application dealing with audio source selection might be > poor usability to some. It all depends on whether the application has/needs a dialog. If it anyway needs a dialog to setup the capture, be it select the video source, define the encoding parameters or the destination, then relying on a separate dialog in another application just for audio input is backward. I would actually like to avoid selecting the audio input. But that's why I'm trying to find a way to select the correct one, with regards to the selected capture type. I really don't care if the logic has to be in PulseAudio or in VLC. But it does not seem that PulseAudio has enough at this point :( >> So I think it's fair for recording/streaming applications to act as their >> own "volume control tool". Of course, they should play good citizens with >> the other volume control tool(s) in the system, and in particular not >> actively fight changes initiated by the PulseAudio daemon or another >> PulseAudio client. > So what's preventing you from listing all possible input sources in VLC? That's doable, but it is probably not as seamless as could be. It gets worse if PulseAudio remembers the selection and restores it for some unrelated purpose next time. FWIW for plain audio capture, user can choose the input or let PA decide already. >> And in fact, the same applies partly to output (playback/streaming). Any >> reasonable media player has a volume control, and possibly a balance and >> an >> output devices choice list. So long as it lets PulseAudio set the initial >> values and does not prevent other tools from moving or tuning the sink >> input, I must say I don't see a problem. > Show me one modern media player that has output devices choice list. Or > video conferencing, where it would make even more sense (hint: neither > Skype nor Empathy allow you to select sinks/sources). Volume control in > e.g. banshee is just a proxy to PA. So? Volume control and output device selection in VLC 1.2 is just a proxy to PA too. It still is useful. Like if I'm watching a video fullscreen, I'd much rather adjust the volume on the VLC fullscreen controller than go back to windowed mode and open KMix. Especially if my keyboard lacks multimedia keys. Similarly, if the user has multiple audio outputs, say stereo and surround, (s)he might want to change them. I admit I don't use this feature myself, but there is ample evidence that a number of our users do, be they based on PulseAudio or not. > That's just how it was designed, and on purpose. I can imagine a common > (just as printing is now <but wasn't not so long ago> - you generally > always should get a printing dialog you know well) dialog for advanced > applications to choose sinks and sources for a particular app / role on > demand. But I'm not sure that's necessary and I haven't seen anyone step > up and write it. > > Another thing I could imagine is a media role (are those even > implemented for sources?) of "desktop-recorder" or similar, that will > choose the monitor of the active sink for you. That's as far as I'd go, > TBH, to handling this case. Yeah that would be good. But I reckon it's not there (yet) which is why I'm asking what's the correct path. It seems the only solution is to list all inputs then :/ (or extend PulseAudio but my free time is not extensible.) -- R?mi Denis-Courmont http://www.remlab.net/
