Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread David Henningsson

On 10/18/2011 04:06 PM, Rémi Denis-Courmont wrote:

Le mardi 18 octobre 2011 16:35:59 David Henningsson, vous avez écrit :

Btw, as for recording microphone, that does seem adequate to me, e g if
somebody records things like "Now look what happens when I press this
button".


Fair enough, but a PulseAudio client cannot cleanly ask PulseAudio to mix a
microphone and a monitor, or can it?


Hmm...not "cleanly", I think. I think that would require some loading of 
module-combine, -loopback or -null stuff, but other people here would 
know that stuff better than I.


--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Rémi Denis-Courmont
Le mardi 18 octobre 2011 16:35:59 David Henningsson, vous avez écrit :
> Btw, as for recording microphone, that does seem adequate to me, e g if
> somebody records things like "Now look what happens when I press this
> button".

Fair enough, but a PulseAudio client cannot cleanly ask PulseAudio to mix a 
microphone and a monitor, or can it?

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Michał Sawicz
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 


signature.asc
Description: This is a digitally signed message part
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Michał Sawicz
Dnia 2011-10-18, wto o godzinie 14:22 +0200, Rémi Denis-Courmont pisze:
> So where in pavucontrol do I select the VIDEO source? Duh?
As stated in my previous email - there isn't a video mixer. Yet.

> > Even Skype does that now.
> > The drop-downs in Skype's sound preferences only contain "Pulseaudio"
> > here.
> 
> Skype is a voice call and videoconferencing tool. Using the default
> PulseAudio source makes perfect sense there. First time, it will get the
> default microphone. Next time, it will get the source that it had the
> previous time if available. All is good for Skype.
Nope, it doesn't work like that. Every time it will get the source that
is most suitable for a VoIP app. Be it the only microphone, a USB
headset, BT headset or whatever makes most sense. Not until you manually
set a different source will PA restore the selected source for Skype.
Or, actually, for all VoIP apps, in that case.

> If the user selects desktop recording, this does not work.
So the consensus seems to be that the best solution would be a new
'screencasting' media role, as both me and David pointed out in other
posts. That should, IMO, as David wrote, include default microphone,
too. You could mute it, of course, but I don't think a separate
'screencasting+mic' role would make sense. Turn that into a feature
request on PA trac, please, would you?

Cheers,
-- 
Michał (Saviq) Sawicz 


signature.asc
Description: This is a digitally signed message part
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread David Henningsson

On 10/18/2011 12:26 PM, Rémi Denis-Courmont wrote:

 Hello,

One regularly requested feature addition for VLC media player is the
ability to record desktop audio in sync with screen capture.
This is theoretically feasible with a PulseAudio sink monitor source. But
but, I am a it puzzled as how to record the correct source. In this case,
the default source is obviously inadequate, as it would typically be the
microphone. In particular, what to do if there are more than one sink, and
thus more than one monitor??


Hmm. For your use case, it looks like we might need a new "media role" 
in PulseAudio for screencast recording, which would default to "the 
default sink's monitor", but that the user can change.


Btw, as for recording microphone, that does seem adequate to me, e g if 
somebody records things like "Now look what happens when I press this 
button".


--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Rémi Denis-Courmont
On Tue, 18 Oct 2011 15:05:31 +0200, Michał Sawicz 
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  - 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 c

Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Michał Sawicz
Dnia 2011-10-18, wto o godzinie 14:19 +0200, Rémi Denis-Courmont pisze:
--8<--
> Video applications need to provide a choice of video sources (webcams,
> desktop capture...). For this, there is no video mixer applications. In
> terms of usability, I would expect to choose the audio source at the same
> time as the video source.
As you said - there is no video mixer application. Yet.

> 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?

> - 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.

> 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?

> 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.

That's just how it was designed, and on purpose. I can imagine a common
(just as printing is now  - 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.

Cheers,
-- 
Michał (Saviq) Sawicz 


signature.asc
Description: This is a digitally signed message part
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Rémi Denis-Courmont
On Tue, 18 Oct 2011 14:15:13 +0200, Michał Sawicz 
wrote:
> Dnia 2011-10-18, wto o godzinie 14:03 +0200, Rémi Denis-Courmont pisze:
>> If the user has selected "I want to record (or stream) my desktop",
>> how does the application get hold of the desktop audio? In other words
>> how should it select "a" sink monitor source? 
> "It" as in "the application" should not, at all.

Oh really?

> The user should select
> that monitor in his volume-control of choice.

So where in pavucontrol do I select the VIDEO source? Duh?

> Even Skype does that now.
> The drop-downs in Skype's sound preferences only contain "Pulseaudio"
> here.

Skype is a voice call and videoconferencing tool. Using the default
PulseAudio source makes perfect sense there. First time, it will get the
default microphone. Next time, it will get the source that it had the
previous time if available. All is good for Skype.


If the user selects desktop recording, this does not work.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Rémi Denis-Courmont
On Tue, 18 Oct 2011 13:38:39 +0200, Michał Sawicz 
wrote:
> Dnia 2011-10-18, wto o godzinie 13:33 +0200, Rémi Denis-Courmont pisze:
>> Eh? The user doing the recording typically wants to hear the sound
>> while recording. So I don't see what null sink has to do here.
> As long as you only want to record your speakers, then just record the
> monitor of the output sink. The null / loopbacks can help if you want to
> record microphone, too.
> 
>> > Obviously that's not relevant to VLC itself, it's through 
>> > pactl/pacmd (sorry) and pavucontrol that you need to select the 
>> > appropriate recording source.
>> 
>> So that's not an answer to the problem. 
> Yes it is. VLC isn't the place to choose recording inputs. Volume
> control tools are the place to do so.

That's a different topic. But while this looks like a popular conception
among PulseAudio developers, I have to partly disagree.


Video applications need to provide a choice of video sources (webcams,
desktop capture...). For this, there is no video mixer applications. In
terms of usability, I would expect to choose the audio source at the same
time as the video source.

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.
- 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.

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.


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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Michał Sawicz
Dnia 2011-10-18, wto o godzinie 14:03 +0200, Rémi Denis-Courmont pisze:
> If the user has selected "I want to record (or stream) my desktop",
> how does the application get hold of the desktop audio? In other words
> how should it select "a" sink monitor source? 
"It" as in "the application" should not, at all. The user should select
that monitor in his volume-control of choice. Even Skype does that now.
The drop-downs in Skype's sound preferences only contain "Pulseaudio"
here.

-- 
Michał (Saviq) Sawicz 


signature.asc
Description: This is a digitally signed message part
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Rémi Denis-Courmont
On Tue, 18 Oct 2011 13:38:39 +0200, Michał Sawicz 
wrote:
> Dnia 2011-10-18, wto o godzinie 13:33 +0200, Rémi Denis-Courmont pisze:
>> Eh? The user doing the recording typically wants to hear the sound
>> while recording. So I don't see what null sink has to do here.
> As long as you only want to record your speakers, then just record the
> monitor of the output sink. The null / loopbacks can help if you want to
> record microphone, too.
> 
>> > Obviously that's not relevant to VLC itself, it's through 
>> > pactl/pacmd (sorry) and pavucontrol that you need to select the 
>> > appropriate recording source.
>> 
>> So that's not an answer to the problem. 
> Yes it is. VLC isn't the place to choose recording inputs. Volume
> control tools are the place to do so.

> Can you describe your complete usecase? 'Cause I fail to see the actual
> issue at hand.

If the user has selected "I want to record (or stream) my desktop", how
does the application get hold of the desktop audio? In other words how
should it select "a" sink monitor source?

-- 
Rémi Denis-Courmont
http://www.remlab.net/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Michał Sawicz
Dnia 2011-10-18, wto o godzinie 13:33 +0200, Rémi Denis-Courmont pisze:
> Eh? The user doing the recording typically wants to hear the sound
> while recording. So I don't see what null sink has to do here.
As long as you only want to record your speakers, then just record the
monitor of the output sink. The null / loopbacks can help if you want to
record microphone, too.

> > Obviously that's not relevant to VLC itself, it's through 
> > pactl/pacmd (sorry) and pavucontrol that you need to select the 
> > appropriate recording source.
> 
> So that's not an answer to the problem. 
Yes it is. VLC isn't the place to choose recording inputs. Volume
control tools are the place to do so.

Can you describe your complete usecase? 'Cause I fail to see the actual
issue at hand.

Regards,
-- 
Michał (Saviq) Sawicz 


signature.asc
Description: This is a digitally signed message part
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Rémi Denis-Courmont
On Tue, 18 Oct 2011 12:55:13 +0200, Michał Sawicz 
wrote:
> Dnia 2011-10-18, wto o godzinie 12:26 +0200, Rémi Denis-Courmont pisze:
>> One regularly requested feature addition for VLC media player is the
>> ability to record desktop audio in sync with screen capture.
>> This is theoretically feasible with a PulseAudio sink monitor source.
>> But but, I am a it puzzled as how to record the correct source. In
>> this case, the default source is obviously inadequate, as it would
>> typically be the microphone. In particular, what to do if there are
>> more than one sink, and thus more than one monitor??
> 
> See http://www.pulseaudio.org/wiki/Modules and read about
> module-null-sink and module-loopback. You can obviously only record from
> one source (for screencasting - probably a monitor), but you can also
> loop back any number of sources to the sink whose monitor you're
> recording. That can be a null sink, too, so that you don't get feedback
> through your speakers.

Eh? The user doing the recording typically wants to hear the sound while
recording. So I don't see what null sink has to do here.

> Obviously that's not relevant to VLC itself, it's through pactl/pacmd
> (sorry) and pavucontrol that you need to select the appropriate
> recording source.

So that's not an answer to the problem.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Michał Sawicz
Dnia 2011-10-18, wto o godzinie 12:26 +0200, Rémi Denis-Courmont pisze:
> One regularly requested feature addition for VLC media player is the
> ability to record desktop audio in sync with screen capture.
> This is theoretically feasible with a PulseAudio sink monitor source.
> But but, I am a it puzzled as how to record the correct source. In
> this case, the default source is obviously inadequate, as it would
> typically be the microphone. In particular, what to do if there are
> more than one sink, and thus more than one monitor??

See http://www.pulseaudio.org/wiki/Modules and read about
module-null-sink and module-loopback. You can obviously only record from
one source (for screencasting - probably a monitor), but you can also
loop back any number of sources to the sink whose monitor you're
recording. That can be a null sink, too, so that you don't get feedback
through your speakers.

Obviously that's not relevant to VLC itself, it's through pactl/pacmd
(sorry) and pavucontrol that you need to select the appropriate
recording source.

Cheers,
-- 
Michał (Saviq) Sawicz 


signature.asc
Description: This is a digitally signed message part
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


[pulseaudio-discuss] Screen casting with PulseAudio

2011-10-18 Thread Rémi Denis-Courmont
Hello,

One regularly requested feature addition for VLC media player is the
ability to record desktop audio in sync with screen capture.
This is theoretically feasible with a PulseAudio sink monitor source. But
but, I am a it puzzled as how to record the correct source. In this case,
the default source is obviously inadequate, as it would typically be the
microphone. In particular, what to do if there are more than one sink, and
thus more than one monitor??

-- 
Rémi Denis-Courmont
http://www.remlab.net/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss