[pulseaudio-discuss] Detecting when data source disappears?

[Steven Wawryk]

>> I've been reading up and experimenting on both the simple and async
>> APIs.  In one experiment, I used a CLI file that sets up a set of
>> module-sine modules with output remapped by module-remap-sink modules
>> to a stream fed to a module-null-sink module.
>>
>> I then wrote 2 programs, one using the simple API and the other the
>> async API to read date from the module-null-sink monitor source and
>> write the data to file (both based on examples to provide "parec"
>> functionality).  Then I could unload either all the module-sine
>> modules or all the module-remap-sink modules to interrupt the data
>> source to the module-null-sink module.
>>
>> Both programs gave the same result, which I don't completely understand.
>>
>> The issues I've found are:
>>
>> 1. After the data source is gone, the program continues to write data
>> to file.  There doesn't seem to be any way to detect a stream of
>> "zero" data using the APIs.
> That is expected behavior. null-sink.monitor is not different from other
> sources, which means
> if there is no input to the null-sink, it will generate silence. It's
> like recording from an unplugged
> mic or line-in input.
And there's no silence detection?
>> 2. If I run it for 20 seconds, with 10 seconds of sinusoidal data
>> followed by 10 seconds of null data, the file ends up with anything
>> from 30 to 40 seconds worth of data in it.
>>
>> 3. The files written from case 2, above, show the initial sinusoidal
>> data as expected, but then, following data stream interruption, about
>> 5 to 10 seconds of switching back and forth between segments of
>> sinusoidal data and null data, before finally settling to null data
>> only till the end of file.
> Did you test if the same happens with parec? If yes, are there any log
> messages
> during the time?
Just did it and the result is the same.  Attached is the relevant part 
of the syslog.
>> Can anyone explain to me why it behaves like this?  Or if there's
>> something in the async API that I'm missing in detecting null data?
>>

-------------- next part --------------
May 19 12:18:21 walnut02 pulseaudio[6305]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
May 19 12:18:28 walnut02 gnome-session[3836]: (Audacity:6319): Gtk-WARNING **: gtk_disable_setlocale() must be called before gtk_init()
May 19 12:18:29 walnut02 gnome-session[3836]: ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
May 19 12:18:29 walnut02 gnome-session[3836]: ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
May 19 12:18:29 walnut02 gnome-session[3836]: ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
May 19 12:18:29 walnut02 gnome-session[3836]: ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
May 19 12:18:29 walnut02 gnome-session[3836]: Cannot connect to server socket err = No such file or directory
May 19 12:18:29 walnut02 gnome-session[3836]: Cannot connect to server request channel
May 19 12:18:29 walnut02 gnome-session[3836]: jack server is not running or cannot be started
May 19 12:18:29 walnut02 gnome-session[3836]: JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
May 19 12:18:29 walnut02 gnome-session[3836]: JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
May 19 12:18:29 walnut02 gnome-session[3836]: Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4611
May 19 12:18:29 walnut02 gnome-session[3836]: message repeated 4 times: [ Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4611]
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unknown accel modifier: 'left'
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unknown accel modifier: 'click/left'
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unrecognized accel key 'drag', accel string ignored.
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unknown accel modifier: 'left'
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unrecognized accel key 'click', accel string ignored.
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unknown accel modifier: 'right'
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unrecognized accel key 'click', accel string ignored.
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unknown accel modifier: 'left'
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unknown accel modifier: 'click/left'
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unrecognized accel key 'drag', accel string ignored.
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unknown accel modifier: 'left'
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unrecognized accel key 'click', accel string ignored.
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unknown accel modifier: 'right'
May 19 12:18:29 walnut02 gnome-session[3836]: 12:18:29: Debug: Unrecognized accel key 'click', accel string ignored.
May 19 12:18:29 walnut02 gnome-session[3836]: (Audacity:6319): Gdk-CRITICAL **: IA__gdk_window_get_origin: assertion 'GDK_IS_WINDOW (window)' failed
May 19 12:18:29 walnut02 gnome-session[3836]: message repeated 51 times: [ (Audacity:6319): Gdk-CRITICAL **: IA__gdk_window_get_origin: assertion 'GDK_IS_WINDOW (window)' failed]