Brian Cameron wrote: > Bart: > >> Awesome, guys. Thanks for including rhythmbox; it's playing very nicely >> on build 37. Was ekiga included? I don't see it anywhere. > > Glad you are enjoying rhythmbox! > >> Some very minor nigglets on rhythmbox: >> >> * default sound buffering is several seconds; this produces a less that >> immediate response to playlist/volume changes... > > I've spent some time working on this, and am not sure what can be done > to fix this. Note that the volume on the panel (system volume) works > without delay. Just application volume, like in rhythmbox is sluggish. > > The problem is that GStreamer uses a ringbuffer to store data it is > feeding to the audio output. I notice that if I set the ringbuffer to > less than 512K that I get stuttering audio output. It does not seem > that there is a way to specify that the audio output buffer should > be smaller via the SunAudio interfaces. Perhaps this is tunable > somewhere else I don't know about? > > I don't even see a way to check what the audio output buffer size > so I can set it to a smaller value if the audio device actually has > a smaller buffer. > > Am I missing something, or is the SunAudio interface just sucky? > > Brian
Solaris has a mixer in the kernel; it combines each audio stream together and does the volume adjustment for each stream when mixed (a very small fraction of a second before play). If the volume slider on rhythmbox adjusts the level prior to writing the data to the ringbuffer, we're going to get significant "lag" (4 seconds on my machine). Adequate buffering is important in an audio application, although dealing with real-time action games can be tricky (getting the sound right for Quake on Solaris took a little while). In this case, can GStreamer use a hardware volume control rather than a software one? - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
