Closed Bug 695612 Opened 11 years ago Closed 10 years ago

nsRemotedAudioStream::Write is non-blocking

Categories

(Core :: Audio/Video, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla16
blocking-basecamp +

People

(Reporter: kinetik, Assigned: kinetik)

References

Details

Attachments

(1 file)

nsAudioStream consumers expect Write to block when the backend audio buffer is full, and rely on this behaviour to put audio refill threads to sleep until buffer space becomes available.

nsRemotedAudio's Write does not block, and currently has no knowledge of how full the audio stream's buffers it is remoting to actually are.
Blocks: 695986
I don't plan to work on this anytime soon.  The NativeUI Fennec project for Android is single process, which means we can use sydneyaudio (and future audio APIs) directly without the remoted nsAudioStream.
So I don't forget: Oleg's media bridge patch in bug 598868 is useful for pointers on how to do  non-main-thread IPC bridging, which would make fixing this bug much simpler by allowing Write() to be an synchronous inter-audio-thread call.
No longer blocks: 695986
Blocks: 695986
This would be quite easy to do.  We might want this for b2g.
blocking-basecamp: --- → +
Blocks: 766824
Blocks: 761936
Attached patch patch v0Splinter Review
This is kind of a crummy fix, but we already use this technique to make Drain() blocking, so it's super simple to reuse it for Write.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attachment #638266 - Flags: review?(chris.double)
Attachment #638266 - Flags: review?(chris.double) → review+
I spun off bug 770753 for reworking the PAudio protocol to avoid shunting everything through the main threads of each process (which I mentioned in comment 2 in thus bug).
https://hg.mozilla.org/mozilla-central/rev/f39b9c98ab14
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Duplicate of this bug: 766824
Duplicate of this bug: 768272
You need to log in before you can comment on or make changes to this bug.