Dnia 2011-10-18, wto o godzinie 15:31 +0200, R?mi Denis-Courmont pisze: > > 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. So the only real case is ATV, since DVB doesn't go through PA. And that's a special case that needs to be taken care of differently. But the user won't have to select anything here. > 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 :( Yup, a selector for media roles (or even better - automagically selecting what makes most sense) would be my preference, too. > > 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. I don't think with that we can get anything better, the user might want to record from any source available and no role selection will help. > > 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. I agree that a music player needs a volume slider, but a device selector - no. > 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. Not a device selector again. You should be able to select between some of stereo / (analog) surround / digital / passthrough, but not the device you want to use. > > 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.) Depends on what you want to spend your time on. Cheers, -- Micha? (Saviq) Sawicz <michal at sawicz.net> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111018/58f9eec8/attachment.pgp>
