[prev in list] [next in list] [prev in thread] [next in thread] 

List:       alsa-devel
Subject:    [alsa-devel] Re: memory allocation and the hammerfall
From:       Paul Barton-Davis <pbd () Op ! Net>
Date:       1999-12-29 21:00:35
[Download RAW message or body]

In message <Pine.LNX.4.10.9912291120360.29098-100000@anime.net>you write:
>On Wed, 29 Dec 1999, Paul Barton-Davis wrote:
>> i should be getting 2 hammerfalls delivered next monday. i am planning
>> to start port winfried's driver to ALSA in the next couple of
>> days. before i spend to much time on it, do we have a better generic
>> solution for the problem of "large contiguous memory allocation" that
>> he solved with a kernel module ? i believe that there is a bigphysarea
>> patch or config option, but i'm not sure. advice would be welcome.
>
>I think 2.3.x addresses this with the zoned allocators? I know that some
>of the video4linux drivers allocate contiguous blocks of several mbytes
>for video capture.
>
>Can the hammerfalls do scatter-gather dma?

well, to judge from winfried's code, there is no particular control
over the DMA at all. they just get switched into thinking of
themselves as PCI busmasters if they didn't claim to be so, and then they
take off. 

it looks like a *beautiful* system for hdr - just as they claim,
absolutely no CPU cycles associated with recording until you want to
copy data into user space (well, not quite: the interrupt burns a few
cycles, but doesn't happen very often). each channel can be read
individually ie. no de-interleaving or dropping data for unread
channels. plus their excellent punch-in/punch-out system for enabling
zero-latency monitoring on a *per-channel* basis. but i see nothing to
suggest a scatter-gather mode.

note: applications that insist on dealing with and producing
interleaved data will not work with the first version of the ALSA
driver that I do, and even when they do work, they will cause quite a
few extra CPU cycles to be burnt. this is the not the right card to
use for playing back a (normal, interleaved) 24 channel WAV file, for
example: you will have to first copy each channel of the wave file
into its own contiguous buffer, then send them to the card. Instead,
you should plan on using 1 file per channel, as was discussed over on
linux-audio-dev a while back.

--p
------
To unsubscribe from <alsa-devel@alsa-project.org> mailing list send message
'unsubscribe' in the body of message to <alsa-devel-request@alsa-project.org>.
BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs

[prev in list] [next in list] [prev in thread] [next in thread]