From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JsYlC-0005Ss-Uh for qemu-devel@nongnu.org; Sun, 04 May 2008 03:35:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JsYlB-0005SV-6v for qemu-devel@nongnu.org; Sun, 04 May 2008 03:35:50 -0400 Received: from [199.232.76.173] (port=57911 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsYlB-0005SM-2a for qemu-devel@nongnu.org; Sun, 04 May 2008 03:35:49 -0400 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JsYlA-0000Xt-5b for qemu-devel@nongnu.org; Sun, 04 May 2008 03:35:48 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JsYl8-0003JM-Ie for qemu-devel@nongnu.org; Sun, 04 May 2008 03:35:46 -0400 Message-ID: <481D670D.6070602@web.de> Date: Sun, 04 May 2008 09:34:37 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <481B6626.7010603@web.de> <481B80F0.8050705@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8ABA59A872AA1C9BD5698AD3" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH] alsaaudio: increase default buffer sizes Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8ABA59A872AA1C9BD5698AD3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable malc wrote: > On Fri, 2 May 2008, Jan Kiszka wrote: >=20 >> malc wrote: >>> On Fri, 2 May 2008, Jan Kiszka wrote: >>> >>>> Sound though the ALSA driver is skipping here unless I increase the >>>> buffer size. OSS seems to use 16K as well, and 1K was obviously to >>>> small >>>> for recording anyway. >>>> >>>> [ PS: Can someone explain to me why I also have to override the >>>> DAC/ADC_FIXED_FREQ to 48000 to make ALSA work? Suboptimal... ] >>> >>> How exactly it doesn't work if you don't override it? Do you get any >>> messages prefixed with "alsa:"? As for the defaults they were set to >>> 1024/256 because that's what was needed to make it sound on par with = OSS >>> on the two machines i had at the time. >> >> alsa: Could not initialize ADC >> alsa: Failed to set period size 256 >> alsa: Reason: Invalid argument >=20 > The code first asks for minimal period size than adjusts period_size to= be > no less than the obtained value then calls set_period which fails, ther= e's > little that can be done which ammounts to(never tested): >=20 > diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c > index 43cfa25..ca17bc0 100644 > --- a/audio/alsaaudio.c > +++ b/audio/alsaaudio.c > @@ -428,15 +428,15 @@ static int alsa_open (int in, struct > alsa_params_req *req, > } > } >=20 > - err =3D snd_pcm_hw_params_set_period_size ( > + err =3D snd_pcm_hw_params_set_period_size_near ( > handle, > hw_params, > - period_size, > + &period_size, > 0 > ); > if (err < 0) { > alsa_logerr2 (err, typ, "Failed to set period size= > %d\n", > - req->period_size); > + period_size); > goto err; > } > } >=20 >=20 > Could you give it a whirl please? No difference - except that it now complains about the 16384 byte buffer size. What indirect effect has the frequency difference (44k1 vs. 48k) on this size parameter, on its valid range, or whatever? Or is this service simply always failing because of a certain ALSA state? >=20 > [..snip..] >=20 >> >> BTW, I picked up those ALSA settings from user reports on kvm-devel, >> dating back to mid of last year. So I'm not alone, and it shouldn't be= a >> wm8750-specific thing. >> >>> >>> By the by: OSSs fragment size is specified in bytes, ALSAs on the oth= er >>> hand in frames. So 16*1024 in the patch bellow means(considering >>> S16/stereo) 65536 bytes large buffer and 1024 bytes large period. For= >>> OSS it's 16K bytes buffer and 4096 bytes period. >>> >> >> Ah, OK. However, 4*1024 is not enough for the DAC here, and there were= >> similar reports by kvm users. >=20 > It's apparently plenty enough for ALSA when it emulates OSS and not whe= n > it does things "native" way, oh boy. Maybe something else is broken, and this just happens to be a workaround. But I've no experience with the ALSA API, I'm only guessing. Jan --------------enig8ABA59A872AA1C9BD5698AD3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIHWcSniDOoMHTA+kRAn2TAJ4w196xoKPpeeCLGTX1hb+L/C78SQCfR1Xn QHFl5QZk3UG4TN/bhAUtpZk= =e5zn -----END PGP SIGNATURE----- --------------enig8ABA59A872AA1C9BD5698AD3--