Bugzilla

Is the reason of increasing the size of SPSC queue that we want to make sure the audio stream won't be starved (as much as possible) when MDSM is entering the extreme situation decribed in [your document](https://docs.google.com/document/d/1neg2NRuAkNygKWOTeVW37l7S1xjjH8JK_JgXl7d26O0/edit#bookmark=id.oqwahprkkjwv) (thread is still waiting for next scheduling)? 

However, from my observation, when I play audio (on MacBook M1) under `$ stress-ng  --cpu 32 --bigheap 32`, the SPSC queue is usually used around only 50% usage, it still has plenty of room to store audio, so I'm not sure adding more spaces would be helpful.

I also got an [interesting profile](https://share.firefox.dev/3B4CcC9) in which you can see a gap happening around `65s`. That gap is different from Bobby's profile, because it seems caused by `NativeAudioCallback`. You can see there are two `NativeAudioCallback`, the first one stops around `65s` and another one starts after that, which seems a cause for the gap. 

I feel like what happened in Bobby's profile is that, propbably our audio clock didn't update in time (I guess? because I'm not familiar with how we get the clock from the audio IPC) First, the thread scheduling was already slow under that extreme situation. So the checking happens in MDSM won't be performed frequently. If the clock time are updated too slow, because it requires getting time from remote audio process. The slow clock time would further affect the both rendering video and requesting audio decode tasks. For video, we [calculate the delta] based on the audio clock to deteminine the time of rendering next video. For audio, we calculate [decoded audio duration based on the audio clock](https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/dom/media/MediaDecoderStateMachine.cpp#2897-2901) to see if we still need to dispatch an audio decoding task.

Is the reason of increasing the size of SPSC queue that we want to make sure the audio stream won't be starved (as much as possible) when MDSM is entering the extreme situation decribed in [your document](https://docs.google.com/document/d/1neg2NRuAkNygKWOTeVW37l7S1xjjH8JK_JgXl7d26O0/edit#bookmark=id.oqwahprkkjwv) (thread is still waiting for next scheduling)? 

However, from my observation, when I play audio (on MacBook M1) under `$ stress-ng  --cpu 32 --bigheap 32`, the SPSC queue is usually used around only 50% usage, it still has a plenty of room to store audio, so I'm not sure adding more spaces would be helpful.

I also got an [interesting profile](https://share.firefox.dev/3B4CcC9) in which you can see a gap happening around `65s`. That gap is different from Bobby's profile, because it seems caused by `NativeAudioCallback`. You can see there are two `NativeAudioCallback`, the first one stops around `65s` and another one starts after that, which seems a cause for the gap. 

I feel like what happened in Bobby's profile is that, propbably our audio clock wasn't updated in time (I guess? because I'm not familiar with how we get the clock from the audio IPC) First, the thread scheduling was already slow under that extreme situation. So the checking happens in MDSM won't be performed frequently. If the clock time are updated too slow, because it requires getting time from remote audio process. The slow clock time would further affect the both rendering video and requesting audio decode tasks. For video, we [calculate the delta] based on the audio clock to deteminine the time of rendering next video. For audio, we calculate [decoded audio duration based on the audio clock](https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/dom/media/MediaDecoderStateMachine.cpp#2897-2901) to see if we still need to dispatch an audio decoding task.

Is the reason of increasing the size of SPSC queue that we want to make sure the audio stream won't be starved (as much as possible) when MDSM is entering the extreme situation decribed in [your document](https://docs.google.com/document/d/1neg2NRuAkNygKWOTeVW37l7S1xjjH8JK_JgXl7d26O0/edit#bookmark=id.oqwahprkkjwv) (thread is still waiting for next scheduling)? 

However, from my observation, when I play audio (on MacBook M1) under `$ stress-ng  --cpu 32 --bigheap 32`, the SPSC queue is usually used around only 50% usage, it still has plenty of room to store audio, so I'm not sure adding more spaces would be helpful.

I also got an [interesting profile](https://share.firefox.dev/3B4CcC9) in which you can see a gap happening around `65s`. That gap is different from Bobby's profile, because it seems caused by `NativeAudioCallback`. You can see there are two `NativeAudioCallback`, the first one stops around `65s` and another one starts after that, which seems a cause for the gap. 

I feel like what happened in Bobby's profile is that, propbably our audio clock wasn't updated in time (I guess? because I'm not familiar with how we get the clock from the audio IPC) First, the thread scheduling was already slow under that extreme situation. So the checking happens in MDSM won't be performed frequently. If the clock time are updated too slow, because it requires getting time from remote audio process. The slow clock time would further affect the both rendering video and requesting audio decode tasks. For video, we [calculate the delta] based on the audio clock to deteminine the time of rendering next video. For audio, we calculate [decoded audio duration based on the audio clock](https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/dom/media/MediaDecoderStateMachine.cpp#2897-2901) to see if we still need to dispatch an audio decoding task.

Is the reason of increasing the size of SPSC queue that we want to make sure the audio stream won't be starved (as much as possible) when MDSM is entering the extreme situation decribed in [your document](https://docs.google.com/document/d/1neg2NRuAkNygKWOTeVW37l7S1xjjH8JK_JgXl7d26O0/edit#bookmark=id.oqwahprkkjwv) (thread is still waiting for next scheduling)? 

However, from my observation, when I play audio (on MacBook M1) under `$ stress-ng  --cpu 32 --bigheap 32`, the SPSC queue is usually used around only 50% usage, it still has plenty of room to store audio, so I'm not sure adding more spaces would be helpful.

I also got an [interesting profile](https://share.firefox.dev/3B4CcC9) in which you can see a gap happening around `65s`. That gap is different from Bobby's profile, because it seems caused by `NativeAudioCallback`. You can see there are two `NativeAudioCallback`, the first one stops around `65s` and another one starts after that, which seems a cause for the gap. 

I feel like what happened in Bobby's profile is that, propbably our audio clock wasn't updated in time (I guess? because I'm not familiar with how we get the clock from the audio IPC) First, the thread scheduling was already slow under that extreme situation, so the checking happens in MDSM won't be performed frequently. If the clock time are updated too slow, because it requires getting time from remote audio process. The slow clock time would further affect the both rendering video and requesting audio decode tasks. For video, we [calculate the delta] based on the audio clock to deteminine the time of rendering next video. For audio, we calculate [decoded audio duration based on the audio clock](https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/dom/media/MediaDecoderStateMachine.cpp#2897-2901) to see if we still need to dispatch an audio decoding task.

Is the reason of increasing the size of SPSC queue that we want to make sure the audio stream won't be starved (as much as possible) when MDSM is entering the extreme situation decribed in [your document](https://docs.google.com/document/d/1neg2NRuAkNygKWOTeVW37l7S1xjjH8JK_JgXl7d26O0/edit#bookmark=id.oqwahprkkjwv) (thread is still waiting for next scheduling)? 

However, from my observation, when I play audio (on MacBook M1) under `$ stress-ng  --cpu 32 --bigheap 32`, the SPSC queue is usually used around only 50% usage, it still has plenty of room to store audio, so I'm not sure adding more spaces would be helpful.

I also got an [interesting profile](https://share.firefox.dev/3B4CcC9) in which you can see a gap happening around `65s`. That gap is different from Bobby's profile, because it seems caused by `NativeAudioCallback`. You can see there are two `NativeAudioCallback`, the first one stops around `65s` and another one starts after that, which seems a cause for the gap. 

I feel like what happened in Bobby's profile is that, propbably our audio clock wasn't updated in time (I guess? because I'm not familiar with how we get the clock from the audio IPC) First, the thread scheduling was already slow under that extreme situation, so the checking happens in MDSM won't be performed frequently. If the clock time are updated too slow, because it requires getting time from remote audio process. The slow clock time would further affect the both rendering video and requesting audio decode tasks. For video, we [calculate the delta](https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/dom/media/mediasink/VideoSink.cpp#379-386) based on the audio clock to deteminine the time of rendering next video. For audio, we calculate [decoded audio duration based on the audio clock](https://searchfox.org/mozilla-central/rev/4615b544a0f7166233c409c619b426c4025467a7/dom/media/MediaDecoderStateMachine.cpp#2897-2901) to see if we still need to dispatch an audio decoding task.