[pulseaudio-discuss] [RFC] disabling monitor source patch

[Colin Guthrie]

'Twas brillig, and David Henningsson at 04/11/10 09:14 did gyre and gimble:
> On 2010-11-03 10:35, pl bossart wrote:
>> Hi,
>> As part of the passthrough/compressed data support in PulseAudio, we
>> need to disable monitoring. The main use of monitoring is to build
>> peakmeters to show volume information, and that just doesn't make
>> sense for compressed raw data....
> 
> I have also been using it several times to record things as streaming
> music, skype conversations etc. So I would say that the peak meters are
> not the only main usage of monitoring.
> 
> Also, we always have a sink and a source, because of module-auto-sink
> that adds a null sink (and a monitor of that) if no sinks exists. If we
> end up having no sources at all, would that open up a can of worms?

It possibly would, but it should be trivial to write a
module-null-source module and have a module-always-source. Generally
speaking it wouldn't kick in (due to the monitor of a sink), but perhaps
it's actually better to have a totally separate non-monitor source in
the case of no real h/w.

I recently helped someone debug a strange case where they had two
virtual machines running on top of a system with no sound h/w. He was
confused as to why each machine could play audio but when they recorded,
they actually got the product of both machines audio.

With a "proper" null source, they would both record silence which is
probably the more expected result in such situations.

> I would say to go with keeping the monitoring source - either decode it,
> leave the raw data as it is, or write zeroes, whatever we conclude is
> the best way to go.

I think it would feel "wrong" to have an inaccurate monitor source, so
IMO writing zeros is just lying to the consumers of the monitor. I'm not
against decoding for monitoring but by the same token, this is also in
accurate as we would have to sync up the timings of our version vs. the
externally-decoded one which isn't going to be fun.

I'd probably be in favour of no monitor in that case, but I've probably
not fully considered all the problems that crop up under these
circumstances.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]