Re: hardware channel mixing

[Manuel Jander <manuel.jander@usm.cl>]

Hi Lee,

On Sun, 2004-09-05 at 01:06, Lee Revell wrote:
> On Sat, 2004-09-04 at 23:02, Manuel Jander wrote:
> > Hi Lee,
> > 
> > On Sat, 2004-09-04 at 19:28, Lee Revell wrote:
> > > On Fri, 2004-09-03 at 21:19, Manuel Jander wrote:
> > > > Hi,
> > > > 
> > > > [snip]
> > > It certainly can, works great for capture.  I can record 8 channels at
> > > 32 frames, it works perfectly.  I suspect I could record more but
> > > there's some kind of mixer settings bug.
> > 
> > Using one single DMA channel ?
> > 
> 
> Yes.  Although, this is a unique feature of the FX8010 capture device. 
> For capture there is only a single DMA channel for the FX8010 and you
> set bits in a hardware register to select which of the the 64 FX8010
> outputs you want to record.  The hardware imposes some sanity, there is
> a fixed table of allowed buffer sizes, and the number of channels record
> must be a power of two.
> 
> The playback hardware does not work this way.  You can only do one mono
> PCM stream per DMA channel.  My proposal would still use one DMA channel
> per mono PCM, but where the driver currently will only allocate voices
> one or two at a time (which is two or three with the extra voice), this
> would use 17 voices - 16 "data channels" and the "control channel" aka
> the extra voice.

That sounds completely reasonable.

> > > > . I
> > > > think more than 4 or 6 interleaved channels per DMA is not very sane.
> > > 
> > > Why?  It's more efficient than handling them in chunks of 4.  This would
> > > be intended for use by the sound server, in this case jackd; you would
> > > launch jackd with an 8 channel input and 8 channel output device,
> > > corresponding to the analog ins and outs on the hardware.  With 16 or 32
> > > channels the rest are just FX buses.  And this all lives in hardware.
> > 
> > No need to handle them in chunks of specifically 4. But using more than
> > one single DMA channel to relieve the CPU. If not, it would be better
> > using programmed I/O instead of DMA.
> > 
> 
> I am not sure I understand.  How would it tax the CPU more heavily?  You
> end up doing more work at each interrupt, but you have fewer interrupts.

If the IRQ's are fired at a lower rate (fewer IRQ per time unit), you
will have less processing overhead at the cost of higher latency.
Handling a period elapsed event takes CPU time. If there are fewer of
those events, or fewer channels packed into each period that means more
time for each period. Unfortunately we are limited by a maximal period
size of only 4KiB on x86's. Making them bigger is out of question.
Its a matter of tradeoff between how many IRQ you can handle per second
and how low you want the latency to be.

I did some calculation, which yield that with 64 channels, 4KiB of
period size at 44100Hz 16bits would trigger one IRQ each 725us approx.
That is not that bad after all. On low end machine maybe this could
cause xruns, but i guess that trying it out would give a definite
answer.

Best Regards

Manuel Jander




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click