Re: emu10k1 latency / capture period

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

Jaroslav Kysela wrote:

> On Tue, 22 Jun 2004, Takashi Iwai wrote:
> 
> 
>>At Mon, 21 Jun 2004 16:20:38 -0400,
>>Lee Revell wrote:
>>
>>>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.
>>
>>Even if we ignore the capture interrupts and use an additional
>>interrupt source (e.g. an extra playback stream), the size of capture
>>buffer still must follow the restriction.  That is, the minimal
>>capture buffer size is still 384 x 2 bytes, although the period size
>>can be set independently to smaller than 384 bytes. 
> 
> 
> You can do lowlatency even with huge ring buffer, if you have a good
> interrupt / scheduling timer, but it requires changes in application.
> 

This is why I suggested adding an additional hardware device (it
would be hw:x,3), rather than modifying the current one, so that 
applications which expect the current behavior will not break.

I believe that the current driver does not support direct
capture/playback of the FXBus channels - the current FX8010/EFX device
just exposes the GPR-mapped FX8010 outputs, and is apparently just used
for AC3 passthrough.

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