Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Aug 2001 11:47:03 -0400
From:      The Anarcat <anarcat@anarcat.dyndns.org>
To:        freebsd-multimedia@freebsd.org
Subject:   precisions of pcm driver problems and update of rec program
Message-ID:  <20010821114703.B5114@shall.anarcat.dyndns.org>

next in thread | raw e-mail | index | archive | help

--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: <SB16 DSP 4.16> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010821114703.B5114>