On Thu, Jul 09, 2009 at 05:41:18AM -0700, J?rgen Keil wrote: > > > 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. >
hm. interesting. so fyi, AUDIO_GETINFO is an old sun audio style ioctl. earlier you mentioned that you were running b117, which has the new boomer audio support, which means that really applications should use the new OSS audio interfaces instead of the old audio interfaces. i recently ran into a problem where gstreamer on my laptop was defaulting to using sun audio interfaces when really it should be using oss interfaces. you can see descriptions of the problem (and how i debugged it) here: 10036 gstreamer is confused by post-boomer audio devices http://defect.opensolaris.org/bz/show_bug.cgi?id=10036 6853163 audio problems on a toshiba laptop with intel 82801I (ICH9 Family) http://bugs.opensolaris.org/view_bug.do?bug_id=6853163 iirc correctly rhythmbox normally uses gstreamer for audio outout. so it would be interesting to determine if in your case gstreamer is once again using the wrong plugin, and if switching plugins has any effect on audio output. i'm using songbird, which also uses gstreamer, and it also skips unberably. i have to make it a real time process to be able to listen to anything, and even then i still can't do compiles at the same time. turns out it's also writing tiny amounts of data to the audio device. here's what i'm seeing there: ---8<--- /48: write(66, "1104E2051301D702BAFE ;FD".., 1060) = 1060 /48: write(66, "F4FD96FA E\0\0FD1D02E9FF".., 1060) = 1060 /48: write(66, " C\v1D\b /\n p05BA0E1D07".., 1060) = 1060 /48: write(66, "9F041703 604 g03A7\0B401".., 1060) = 1060 /48: write(66, "91FCF4FB1C03 \\0 b03 K02".., 1060) = 1060 /48: write(66, "C1FE OFD9B01\t\0EFFF1401".., 1060) = 1060 /48: write(66, " FFF v\0E203 P02F207E305".., 1060) = 1060 /3: write(24, "FA", 1) = 1 /1: ioctl(66, _ION('P', 23, 4), 0x0804555C) = 0 ---8<--- this is after i went into songbird Tools -> Options -> Playback and set the Audio Output Buffer to 5000 ms (it initially was 1000 ms). it looks like this tiny output buffer usage may be independant of the output plugin in use. in which case this is really a gstreamer issue. have you by filed a bug on this yet? this seems like pretty broken behavior. if you don't want to file a bug then let me know and i'll file one. ;) ed
