From owner-freebsd-multimedia Tue Aug 21 8:46:11 2001 Delivered-To: freebsd-multimedia@freebsd.org Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by hub.freebsd.org (Postfix) with ESMTP id 5A24D37B401 for ; Tue, 21 Aug 2001 08:46:03 -0700 (PDT) (envelope-from anarcat@anarcat.dyndns.org) Received: from khan.anarcat.dyndns.org ([65.92.160.180]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010821154602.HYUH10424.tomts5-srv.bellnexxia.net@khan.anarcat.dyndns.org> for ; Tue, 21 Aug 2001 11:46:02 -0400 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id 811E518BC for ; Tue, 21 Aug 2001 11:48:20 -0400 (EDT) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id 093C420AFC; Tue, 21 Aug 2001 11:47:03 -0400 (EDT) Date: Tue, 21 Aug 2001 11:47:03 -0400 From: The Anarcat To: freebsd-multimedia@freebsd.org Subject: precisions of pcm driver problems and update of rec program Message-ID: <20010821114703.B5114@shall.anarcat.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline User-Agent: Mutt/1.3.20i Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. I have made a few more updates to my rec program, since my last post (aug 15). The program now fully conforms (I think) to the new OSS API as described in the PDF. Display has been improved, a play mode has been implemented, and a few other things has been changed (see the ChangeLog). Now, I still have a few problems, and a few answers. I will include here my BUGS file and comment on it. --- 8< cut here 8< --- BUGS file Bugs in the rec program. Issues are classified by order of importance, higher up. Driver issues (?) ================= Are these issues from the pcm driver or the app? 1) -r 110 make ioctl SNDCTL_DSP_SPEED fail with EINVAL instead of correcting it ("Also note that this call rarely returns an error (-1). Getting an OK result doesn't mean that the requested sampling rate was accepted. The value returned in the argument needs to be checked." - oss.pdf) 2) core dumps if -c 0. This is because the driver doesn't switch to a proper (eg. 1 or 2) value when given such insane values. I digged a bit in the driver code and I found a CHANNEL_SETSPEED macro (? in channel.c:1126) that seems to be the guilty party. I can't find the source of this macro. 3) dsp vs dspW issues it seems that the data is "filled" when in RAW, sample: 00000000: 43fe 8efe 37fe 9dfe 3ffe 90fe 3efe 8dfe C...7...?...>... 00000010: 3dfe 97fe 44fe 93fe 31fe 95fe 48fe 9efe =...D...1...H... 00000020: 38fe 95fe 3dfe 94fe 36fe 9bfe 37fe 8afe 8...=...6...7... This does not happen in the new version, when using -d /dev/dsp and -w, but still happens with -d dspW and -w, which is odd. 4) it seems we can independantly specify dsp and dspW (ie dsp can record 8 bit?), it's just that dspW scraps 16 bit output (!!) App issues ========== I think these are apps isues. 1) check signed issues when recording in AFMT_S16_LE (unsigned char vs signed format), this might be the cause of our lovely "flanger" effect 2) -c n where n > 2 will likely not work. 3) we assume that AFMT_U8 is 8 and that AFMT_S16_LE is 16. 4) we do not always record PCM signed linear 2's complement as claimed because of a few things: a) /dev/dsp vs /dev/audio (linear 2's complement vs mu-law) b) /dev/dsp vs /dev/dspW (unsigned vs signed) "(/dev/dsp used 8-bit unsigned, /dev/dspW uses 16-bit signed little-endian and /dev/audio uses mu-law)" - oss.pdf, p. 29 5) we might not always record full samples ((size / 8) * channels) because of customizable bufsize (solved) and interrupts (not solved) 6) AIFF mode has not been tested with this year's changes 7) Recording AIFF files with .aif file extension records nothing 8) Recording AIFF files seems to be buggy altogether: 3 time the size 9) time spec calculations are invalid in AIFF --- 8< cut here 8< --- Another thing... Is really dsp unsigned and dspW signed, as per the OSS API? I guess that using dsp in 16 bits will automatically put it in signed mode, but I have that flanger effect that I didn't have before here, it might be due to my hardware though. Note that: FreeBSD Audio Driver (newpcm) Aug 1 2001 18:54:11 Installed devices: pcm0: at io 0x220 irq 5 drq 1:5 (1p/1r channels duplex) Please test at will and comment. I think I'm almost there! :) Oh, and note that the AIFF mode is in the way of being deprecated. I have no time test and adapt to the massive latest changes. I request help here. I might work on this once the "raw" version is stable. A. --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuCgnUACgkQttcWHAnWiGfE5ACfRtMjaie/506zcK3iolRdWqVr MJYAn15Yg99oRCf4hzi7dkUE2+FHlo+4 =inBE -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message