On Mon, Mar 05, 2012 at 11:04:00AM +0100, David Coppa wrote: > I'd like to remove this "write_size" constraint, as suggested by > jakemsr@ some time ago: >
afaiu, removing it is desirable, but might be tricky (see below). Does removing it improve stability? > http://marc.info/?l=openbsd-ports&m=128630571914847 > > http://marc.info/?l=openbsd-ports&m=128630890119517 > > As jake said, 1024 bytes is only 256 samples of 16-bit stereo. > At 44.1kHz, that's only 5.8 miliseconds. If mpd takes more than > 5.8 ms between writes, for whatever reason, it will skip. > So, this represents a performance penalty on fast machines and > afaik sndiod should already cope with eventual stuffups just > fine on slower ones... > > Alexandre, what do you think about this? Is it reasonable? write() blocks until the last byte of the chuck is stored in the device buffer. If the chuck is very large then write() will block for very long and the program will idle instead of decoding more data; in this case, the program doesn't use the cpu optimally which may cause drops on slow or busy systems. So it's more efficient to write small chuncks of audio, ideally a small multiple of the device block size. Unfortunately, libao doesn't expose the device block size, afaiu that's why mpd lets the user enter it manually. Using a small chuck like 1024, should make mpd work on most setups. I see no elegant fix that wouldn't involve libao api change or switching to another backend. -- Alexandre
