[gstreamer-bugs] [Bug 360673] Stuttering with SunAudio Sink

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=360673

  GStreamer | gst-plugins-base | Ver: HEAD CVS





------- Comment #17 from Wim Taymans  2006-11-14 12:44 UTC -------
Above analysis is pretty accurate. 

 Thread 3: This is the streaming thread doing all the decoding and eventually 
           writing samples in the ringbuffer. This function can block on a
GCond
           when the ringbuffer is full.

 Thread 4: This is a thread that reads from the ringbuffer and writes to the
           audio device. It works lockfree so that the only blocking operation
           is the write() call. After writing each segment (segsize bytes) it
           will signal Thread 3 that more space is available in the ringbuffer
           (when needed, atomically checking the waiting flag).

Several assumptions are made:

 a Thread 4 only waits in write(), the other operations are lockfree and fast. 
   Its timeslice is practically never consumed. It should be considered an
   interactive task.
 b Thread 3 is mostly scheduled, hopefully enough to write enough samples in
the
   ringbuffer. It is the only task that requires a lot of CPU and should always
   be scheduled whith lower priority than the other tasks.
 c When thread 4 blocks in the write() it is never much longer than the time of
   the segment (segsize bytes * SECOND) / (bytes_per_sample * samplerate),
which
   is typically a few milliseconds. 
 d Thread 4 is able to write N segments without blocking, it blocks writing
   segment N+1. The segtotal should be set to N. When the write unblocks, at
   least one segment is physically played by the device and a new one queued.

The reason for not blocking in Thread 4 when the ringbuffer is empty is because
it simulates a DMA hardware buffer. This also keeps the audio buffer in the
device maximally filled to further limit the number of dropouts due to
thread scheduling jitter.

If the write() call takes a long time (as in comment #6) (c) is violated and
the total buffer time needs to be increased. If (d) is violated because not
enough segments where allocated, Thread 4 will race ahead and will write
silence. If Thread 3 is not scheduled enough, the ringbuffer will underflow and
silence will be written (dropouts). 

Did you check how pulseaudio compares?


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email