> > My guess is that rhythmbox doesn't buffer (enough) > > data in the sound card driver. It seems to send > > tiny amounts of data (1764 bytes; 10 milliseconds of > > data at 44.1kHz stereo 16-bit) and waits until the > > data buffer becomes empty (or the amount of data > > is lower than some tiny threshold). > > Hi, can I ask how you found thouse numbers out?
truss on rhythmbox, while is was playing an .ogg audio file. I saw something like write(fd, ..., 1764) = 1764 write(fd, ..., 0) = 0 ioctl(fd, AUDIO_GETINFO, ...) where fd was the audio device. Btw: the length 0 write is a special "EOF" marker in the playback stream; when the sun audio driver has consumed such a zero length EOF marker during playback, the struct audio_info.play.eof field is incremented by one. This can be used to monitor how much of the data sent to the audio device driver has been played by the hardware. > If that's the case it looks like it's asking for > trouble! I wonder if the buffer size be configured > somewhere? Don't know. A quick check of rhythmbox' options gui dialog didn't reveal such a setting. One should probably have a look at rhythmbox' source and the sun audio driver in it, to understand why they send such tiny audio data buffers. Maybe they try to avoid blocking in a write to the audio device (in this case setting the audio fd for non-blocking mode would be better), or they try to avoid buffering too much audio data in the device device so that clicking on the play/pause button stops audio immediately (iirc, this could be implemented by pausing audio playback with an AUDIO_SETINFO ioctl and audioinfo.play.pause=1), or maybe they try to avoid audio driver bugs, or ... ??? > Do you think that would be an issue with rhythmbox, > gstreamer, or something in opensolaris? Reason I'm > asking is that I've used rhythmbox under linux for > several years up until recently and have never > experienced this issue on the same hardware. I suspect an issue with rhythmbox' sun audio support. -- This message posted from opensolaris.org
