Re: emu10k1 latency / capture period

[Lee Revell <rlrevell@joe-job.com>]

On Mon, 2004-06-21 at 11:54, Takashi Iwai wrote:
> > > On Wed, 2004-06-16 at 16:14, Lee Revell wrote:
> > > > Hey,
> > > > 
> > > > I am having a problem with the emu10k1 driver where I am unable to set
> > > > the capture period lower than 512.  The result is that the lowest
> > > > achievable input to output latency is in the neighborhood of 40ms.
> > > > 
> > > 
> > > I think I may have solved this problem.  Here is a patch against
> > > alsa-driver-1.0.5a.
> > > 
> > > --- alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c.orig   
> > > 2004-06-19 23:21:09.000000000 -0400
> > > +++ alsa-driver-1.0.5a/alsa-kernel/pci/emu10k1/emupcm.c 2004-06-19
> > > 23:21:12.000000000 -0400
> > > @@ -932,7 +932,7 @@
> > >         spin_unlock_irqrestore(&emu->reg_lock, flags);
> > >         emu->capture_efx_interrupt = snd_emu10k1_pcm_efx_interrupt;
> > >         emu->pcm_capture_efx_substream = substream;
> > > -       snd_pcm_hw_constraint_list(runtime, 0,
> > > SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
> > > +       // snd_pcm_hw_constraint_list(runtime, 0,
> > > SNDRV_PCM_HW_PARAM_PERIOD_SIZE, &hw_constraints_capture_period_sizes);
> > >         return 0;
> > >  }
> > > 
> > > I do not think that the FX8010 capture device is constrained by the 
> > > period size limitations on the standard emu10k1 capture device.
> > 
> > Right, this constraint is invalid.
> 
> Well, after checking the code again, I'm not convinced any more...
> Are you sure that it works without this constraint on half-duplex
> capture?

You are correct, it does not work.  I should have fully tested this 
before posting.

I think I have figured out how the FXBus driver needs to work.

The FXBus device (lets say hw:0,3) has 16 (for SBLive) or 32 
(for Audigy) capture and playback channels, one for each hardware 
FXBus channel.

The capture will be driven by the playback interrupts (I think
EFX_BUFFER(HALF)FULL).  This would look very similar to the 
interrupt handler example #2 in your ALSA driver guide, which 
uses timer interrupts to drive the capture/playback, except 
that for playback, in addition to calling snd_pcm_period_elapsed()
on the playback substream, we also maintain a pointer to the 
corresponding *capture* substream, and call snd_pcm_period_elapsed() 
on it, manually tracking the frames processed in the same way the timer
interrupt example does.

We would ignore interrupts from the the standard capture device
ADC_BUFFER(HALF)FULL.  In order to capture the FXBus channels 
you would have to use ld10k1 to connect inputs and outputs to 
FXBus channels.

I think that one result of this design is that if an FXBus channel 
is opened for capture, and none are open for playback, then  
snd_pcm_period_elapsed() will never get called.  One way to solve 
this would be to open a fake playback substream in the open callback for
the capture.

Also, I think that this design requires all processes opening the FXBus 
device to use the same period size.  I am not sure about this.  
The kX ASIO driver works this way, but that may be a requirement of
ASIO.

Do you see any problems with this design?

Lee




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com