From: GStreamer (bugzilla.gnome.o. <bug...@gn...> - 2009-10-05 19:23:05
|
https://bugzilla.gnome.org/show_bug.cgi?id=597463 GStreamer | gst-plugins-good | git Summary: [pulsesrc] has no lower bound for fragment size Classification: Desktop Product: GStreamer Version: git OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: gst-plugins-good AssignedTo: gst...@li... ReportedBy: ma...@re... QAContact: gst...@li... GNOME target: --- GNOME version: --- Since -good commit 1a8938 ("pulsesrc; cleanups, report real latency"), pulsesrc surrenders control of the segsize to pulseaudio. The latency-time value is given to pulse as a suggestion, but the actual value returned by PA is blindly accepted. This can have bad results for applications with higher latency requirements (intended to reduce buffer handling overhead). I'm mostly thinking about Maemo 5/N900 here, which has the corner case of a pulseaudio that is configured to have a 10ms fixed latency source (this will be fixed in the future). Since this a battery powered device, no application really wants to actually deal with 10ms audio buffers (not even for VoIP calls), so we trade in a little latency for some CPU load and battery life. Attaching proposed patch. The idea is to set the ring buffer segsize to a larger value if pulseaudio picks a fragsize that is too low. This results in the ring buffer transparently joining the smaller buffers coming from pulseaudio into GStreamer buffers of duration equal or close to the requested latency-time. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |