Can you specify the OS on which the problem is observed?
The report marks "Linux", but as far as I know we do not support full screen audio capture on Linux.

I did not write the report with the same OS as the one i test with. The problem is observed on Windows 10.

miu@ could you PTAL - is it tab audio capture?

Windows desktop capture *does* support system-wide loopback audio. IIUC, the media::AudioDeviceDescription::kLoopbackInputDeviceId would be specified, and Windows-specific code in win/audio_low_latency_input_win.cc would know what to do with that.

I'm not sure who owns this, but tommi's in the OWNERS file and seems to have been making changes there over the past few weeks. So, let's start with him. :-)

magnus - can you triage?

qiang, can you take a look?

lienrag63@: Can you share me the app that you can reproduce the bug?

I just tried test.webrtc.org/manual/peer2peer/ but I cannot reproduce it, each time, the packet rate stays at 50/s

Another question: does the audio sounds chopped on the remote side? I think another possibility is that webrtc detects your network condition and decides to do resampling and lower bit rate. 

We are a startup and the app or the code's app can't leave our hardware. And for now, i can't make sample code for this case.
But i did some extra tests and noticed:
- Yes the audio is clearly chopped on the remote size.
- It can happen through wireless network as well as through a gigabit wired local network.
- I was not able to reproduce with a windows 7 computer (same chrome version). I don't have access to other windows computers.
- Since i adapted my code from video only to video + audio, the popup "XXX is sharing your screen and audio with YYYYY" is not closed when the streaming is ended by our website, i didn't find why. I have to close it by the blue "Stop sharing" button. When i try multiple times to launch and close a stream, these popups will accumulate if i do not close them and the frequency of the audio problem is clearly higher when there is multiple popup still on the screen.

Thanks. I'll do more investigation.

For last question, you will need to explicitly stop the stream in javascript, otherwise the stream will remain in the memory.

Since I cannot reproduce on my windows 10 machine, can you try to install this app and see whether the recorded system audio is chopped or not?

https://chrome.google.com/webstore/detail/screen-recorder/gdamcnkmddbfhaadidkhahllkabienpk

1. Play some music or any audio with any method
2. Launch the app
3. Check "Include system audio"
4. Click "Record Desktop"
5. Click "Share"
6. After some time, click "Stop"
7. Then you can choose either play the record out or save it, either is OK
8. Verify the recorded audio is chopped or not, and let me know

I wish to know whether the problem is on the capture part or the sending part.

I executed your test a dozen time : all the recordings were correct, no chopping.

As #19, this sounds like that the capture is good, but something is wrong in the webrtc dropping the audio frame. 

But I cannot reproduce the issue on my windows 10 machine, and thus I cannot know what exactly causes this issue. 

To niklase@, is there a way we can escalate it?

An AEC recording of the problem would help, then you can see exactly what data we get to get encoder. During an active session you open up a new tab at chrome://webrtc-internals/, expand "Create Dump" and check "Enable diagnostic audio recordings". Please attach the recording to the bug.

I joined two files. One with the problem occurring and another without, to detect the difference : the first one is faster (than the other and than the original).

Deleted: audio_debug.5332.source_input.4_withProblem.wav 5.5 MB

audio_debug.5332.source_input.4_withProblem.wav 5.5 MB Download

Deleted: audio_debug.5332.source_input.6_withoutProblem.wav 1.9 MB

audio_debug.5332.source_input.6_withoutProblem.wav 1.9 MB Download

What's the current status on this one?

I think this may be related to https://bugs.chromium.org/p/webrtc/issues/detail?id=6915

Max, could you take a look?

Hmm, would make sense if it's some kind of sample rate confusion. I don't know how desktop capture works though, I'll have to dig through some code for this. The WebRTC issue sounds similar, so I'll have a look at that in parallel.

Looks like I dropped the ball here. lienrag63@, can you confirm whether this is still happening in Chrome M72?