olka @ could you please look into this.please feel free to re-assigned back if needed. thanks in advance !

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The check fails comparing bytes-per-buffer value returned by pa_stream_begin_write() vs AudioParameters one pased into it. (65472 vs. 196608)

Documentation for pa_stream_begin_write() says that
"on return *nbytes can be smaller or have the same value as you passed in". (http://pulseaudio.sourcearchive.com/documentation/1.0/stream_8h_a6cf50cfc4ea8897391941184d74d7dfa.html)

However, the failing check assumes that the returned size will be the same as the passed one. The check was added  3,5 yeasr ago (https://chromiumcodereview.appspot.com/12328097) because the case had never been observed when the values are different.

Known crashes for FullfillWriteRequest:
https://crash.corp.google.com/browse?stbtiq=FulfillWriteRequest

The only one I see is not related (https://crash.corp.google.com/browse?q=&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=&stbtiq=FulfillWriteRequest&reportid=2e9ffcb900000000&index=0)

Lowering the priority.

196608 bytes per buffer can be reached if maximum output buffer size of 8192 is used ( https://cs.chromium.org/chromium/src/media/audio/pulse/audio_manager_pulse.cc?q=pulse+%228192%22&sq=package:chromium&l=41&dr=C) for 12 channels at 16 bps.

In usual cases we have 20 ms buffers at 192kHz at max, so for 8 channels it will be 192 * 20 * 8 * 2 = 61440. That's probably why we never hit the check.

ClusterFuzz testcase 4742838359425024 is flaky and no longer reproduces, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.