Screen casting with PulseAudio

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

 



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>


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

  Powered by Linux