Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Mar 2000 20:58:25 -0800
From:      Ken Marx <kmarx@bigshed.com>
To:        Randall Hopper <aa8vb@ipass.net>
Cc:        freebsd-multimedia@FreeBSD.ORG, Ken Marx <kmarx@bigshed.com>
Subject:   Re: Lost interrupts in snd0 ?
Message-ID:  <38D9A470.FFC819DD@bigshed.com>
References:  <38D823E1.87FDA291@bigshed.com> <20000322225322.A3725@ipass.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Randall,

Thanks for the reply. A bitter, but welcome relief.

So, I don't get all the behaviors you describe (but also don't
run mtv ever). Still, no spurious pops or noises. I do know that
I get a humm though my speakers based on xwindow activity though.
(Never have really understood this one.)

Anyway, I have a few general questions (for lack of intelligent ones):

1. Who is/are supporting the voxware driver for 3.x? Can we get help here?

2. We should diff the 3.2/3.4 i386/isa/sound source, and maybe try
   using 3.2 source in the 3.4 kernel (if possible?). I thought I
   did this diff once and saw no changes, but doing it now between an
   old 3.1 and current 3.2 tree, there're are changes. What do you
   see between 3.2/4?

3. I've been wondering about motherboards. Can bus timings or bios
   settings affect things? My 3.2 box has an FIC PA2013 @ 400mhz.
   What have you got? (Although the fact that you see different
   behavior on the same box w/ different OS's points away from this.)

4. I have tried running OSS on my box. I don't see the long pauses,
   but in an app where I tried playing a wavefile piece wise (doing
   a fresh open of /dev/audio for each snippet), the playback was
   extremely choppy. As if they were building in long timeouts somewhere
   to try and mitigate spurious lost interrupts? Just a wild guess.
  
   Anyway, you can try OSS for free from their web site at
   http://www.opensound.com/. They'll give you an eval license. It
   requires you to build a kernel w/out native sound drivers.

5. Is there a way, other than insturmenting the kernel to keep
   timestamps on all outb() inb() calls to know what the board thinks
   it's doing during these pauses and/or whether it thinks it already
   interrupted back.

6. Is it possible that some how the qlen is incorrectly > 0 hence
   making the snd driver think that it's waiting for something that
   will never occur? I couldn't find it in the code, but that means nothing.

7. Lastly, this is kind of dumb, but you can put some trace in your
   kernel to see how long it's waiting in dma_sync(). I'll include
   this rather ugly hack down below. Know that I played with notching
   down the 10 second DO_SLEEP1() (calls tsleep) timeout value to
   what I thought would be more reasonable - say, 3-4 X 1/16, since
   I figured interrupts should occur about 16/sec. 

   Seems to depend on how the app talks to the board via writes,
   ioctl's, etc. Probably a reason for the 10 sec sleep, but wish I
   knew what it was.

Hope you or someone has something to add to this rambling...

Take care,
k.

-- 
Ken Marx, kmarx@bigshed.com
Continue to leverage our ability to innovate within our technology strategy!!
		- http://cgi.bigshed.com/~kmarx/cgi-bin/speak.cgi

--------------------------------------------------

hack/debug in dmabuf.c:dma_sync()

<snip>....
      while (!PROCESS_ABORTING (out_sleep_flag[dev])
             && audio_devs[dev]->dmap_out->qlen){
      int    chn;
      int tmoutTics = 10 * hz;

      microtime( &t0 );
      DO_SLEEP1(chn, out_sleep_flag[dev], tmoutTics);
      if (TIMED_OUT (out_sleep_flag[dev]) ) {
 
            printf("snd%d dma_sync: timed out. Tics=%d\n", dev, tmoutTics );
            splx(flags);
 
            return audio_devs[dev]->dmap_out->qlen;
 
      }
      microtime( &t1 );
 
/*
 * from /usr/include/sys/time.h under #ifndef KERNEL
 * since i didn't grok timevalsub. stupid.
 */
#define timersub(tvp, uvp, vvp)                                     \
    do {                                                            \
            (vvp)->tv_sec = (tvp)->tv_sec - (uvp)->tv_sec;          \
            (vvp)->tv_usec = (tvp)->tv_usec - (uvp)->tv_usec;       \
            if ((vvp)->tv_usec < 0) {                               \
                    (vvp)->tv_sec--;                                \
                    (vvp)->tv_usec += 1000000;                      \
            }                                                       \
    } while (0)
 
      timersub( &t1, &t0, &dt );
      printf("sync time: %ld secs, %ld usecs\n", dt.tv_sec, dt.tv_usec );
    }

   
Randall Hopper wrote:
> 
> Ken Marx:
>  |I'm seeing intermitent long (> 10 sec) pauses in
>  |the snd (voxware) driver, that look to be possibly due
>  |to lost interrupts.
>  |
>  |This is on 3.2 and 3.4 hosts, AMD K6-III and K7, respectively.
>  |Both use a Creative AWE64 isa soundcard.
> ...
>  |Just to make matters more confusing, a friend in the UK is also
>  |running 3.2 on an AMDK6-III, same soundcard, and can't reproduce
>  |this problem.
>  |
>  |Can anyone please help? I'm pretty week on how the sound stuff
>  |is supposed to work, and am kind of running low on ideas?
> 
> So it's not just me!  I too was running well with my Creative SB32 (mostly
> the same as your card) with 3.2R and my AMD K6-III.  Upgrading to 3.4R, I
> also seem to see more hangs on close.
> 
> 2) I also see much longer skips with mtv (the same mtv executable and same
> MPEG streams) than I did with 3.4R.  It behaves like some bad changes were
> made to the SNDCTL_DSP_GETOSPACE or related buffer-query calls.
> 
> 3) Finally, every so often I get 3-10 second bursts of "loud" static (pops,
>    and noise sputters) out of my soundcard when no app is doing sound.
>    This never happened/happens on 3.2R so something is very likely amiss
>    in the sound code.
> 
> FWIW, I have both 3.2R and 3.4R both installed on seperate partitions so
> it's easy for me to multiboot back and forth to compare.
> 
> Randall

-- 
Ken Marx, kmarx@bigshed.com
Continue to leverage our ability to innovate within our technology strategy!!
		- http://cgi.bigshed.com/~kmarx/cgi-bin/speak.cgi


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?38D9A470.FFC819DD>