From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Re: [Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok] Date: Wed, 19 Jan 2005 10:35:42 +0100 Message-ID: References: <1104311474.2984.2.camel@krustophenia.net> <1105647075.3457.18.camel@krustophenia.net> <20050118202309.GA1147@rz.uni-karlsruhe.de> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20050118202309.GA1147@rz.uni-karlsruhe.de> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Reimar =?ISO-8859-1?Q?D=F6ffinger?= Cc: Lee Revell , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Tue, 18 Jan 2005 21:23:09 +0100, Reimar D=F6ffinger wrote: >=20 > Hi, > On Thu, Jan 13, 2005 at 03:11:15PM -0500, Lee Revell wrote: > > Are there any plans to fix the ALSA output so that it doesn't reset t= he > > stream with every xrun? Since you don't use a realtime thread to han= dle > > the audio there are certain to be some xruns, for example whenever us= ing > > the GUI controls in any way or moving the mouse. >=20 > xruns just should not happen. Ignoring them seems to be the very wrong > way. Also a real-time thread should not be necessary just to avoid xrun= s > when only moving the mouse IMHO. No, it's not guaranteed at all. > Maybe you can just increase the buffer size somehow? At least for > MPlayer a big buffer should cause no problems. The hardware buffer size is limited. Suppose the hardware which can have the max buffer size 64kB. When you play a DVD with 5.1 output, it corresponds to 0.11 second. The dedicated audio thread works better than the single thread model because of the following reasons (maybe more): - It has a large intermediate buffer. The buffer size can be as large as you like. - It runs only in short time and sleeps. This is the preferred behavior for the kernel scheduler. So, this thread may receive higher priority bonus. - You can change the priority of only audio thread but keep others. Takashi ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt