On 19.05.2017 06:02, Steven Wawryk wrote: > > >>> 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. Could you please include the command sequence you are using? Maybe I can reproduce the problem here. >>> >>> 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? No, there isn't. This would have to be implemented on application level. >>> 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. This looks like a bug but the log is not verbose enough. The best way to get more information is to run pulseaudio with debugging enabled. You might need to disable autospawn in client.conf or stop the user service when using systemd before you can do so. Then run pulseaudio -vvvv from the command line.
