On Sat, 26 May 2007, Joachim Förster wrote:

Hi ALSA devs,

as I already described in one of my last posts on the list, I'm going to write a ALSA driver for a sound controller which will also be "written" at the same time (VHDL for FPGA) - on top of an embedded system (Xilinx ML403 EvalBoard, PowerPC 405). We will do playback feature only.

The point is, that we will have _no_ real DMA and we don't want to use the copy/silence or ack/workqueue (with intermediate buffer). So we decided to move the ring buffer, which usually exists in RAM into the sound controller and handle it as some kind of device IO memory, which should be mmap'able (kernel function io_remap_pfn_range()). So, the important goal is, to have mmap feature in the ALSA driver.

First question: To implement mmap on such kind of device IO memory, I have to use snd_pcm_lib_mmap_iomem() as mmap() callback - like it is used in the rme32 driver, right?

Yes. rme32 is quite similar.

Second question: Do the following parameters make sense regarding the size of the HW ring buffer and period sizes:

.buffer_bytes_max=16*1024; .period_bytes_max=8*1024; .period_bytes_min=?? resonable value ??

32 or 64

.periods_min=2; .periods_max=?? resonable value ??

16

Furthermore, the sound controller will fire an interrupt after one period is played. Are there any arguments against these values? Any comments?

Yes, I think that the access through a PCI I/O window to a PCI device is much slower than PCI DMA transfers with bursts. I would really consider to design hardware with real DMA. Of course, if it's only experimental stuff, then don't worry.

Jaroslav

----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs