On Wed, 29 Dec 1999 20:38:48 -0500,
Donn Miller <[EMAIL PROTECTED]> said:
Donn> I just recently did another cvsup, and now newpcm is broken
Donn> again. When I try to play a clip with mpg123, I hear a very
Donn> short burst of the beginning of the clip repeated indefinitely,
Donn> like so:
Donn> "ba ba ba ba ba ba ba ba ba ba ba ba ba ba". I have the ESS
Donn> 1868, of course. Well, I (wisely) saved my old kernel as
Donn> /kernel.good and just booted into that.
Donn> Could you also say what was fixed if you get around to it? I'd
Donn> to learn a little more about the sound driver.
The following things were in the recent mail of mine:
- All ioctl(2)s go to see the secondary buffer(if I have forget nothing).
- chn_setblocksize() changes the size of the secondary buffer.
- chn_mmap() maps the secondary buffer.
- chn_poll() invokes DMA.
- chn_wrintr() performs DMA emulation for pcm devices with no DMA
functionality(requested by nyan).
- SNDCTL_DSP_SETFRAGMENT handles the count correctly.
- GETI/OSPACE returns the number of fragments.
- DMA transfer keeps running upon underrun. Some DSPs seem to end up
with an unpredictable result if the DMA gets stopped followed by
immediate restart. This revokes the change in sys/dev/sound/pcm/channel.c
rev 1.12.
- chn_write() and chn_read() returns EAGAIN for nonblocking if there
are no space to write or data to read.
You can add something like:
printf("chn_write: writing %d bytes, bs->fl = %d, bs->rl = %d, b->fl = %d, b->rl = %d,
b->dl = %d\n", buf->uio_resid, bs->fl, bs->rl, b->fl, b->rl, b->dl);
to see the state of the buffers, especially before and after
triggering DMA transfer(around chn_{wr,rd}intr()) or feeding(around
chn_{wr,rd}feed()). A positive value of b->dl shows that DMA transfer
is taking place.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message