![](https://secure.gravatar.com/avatar/21c96b641c1fea341bf8c485ee77eaf9.jpg?s=120&d=mm&r=g)
Takashi Iwai wrote:
On a side note, I notice that ALSA has some scatter-gather support. If an application uses S/G, I presume the concept of a DMA buffer size doesn't even apply?
The SG-buffer isn't for applications but for drivers. From the application viewpoint, the buffer looks linear.
Yes, but in SG, the application allocates the DMA buffer, and a list of physical addresses is passed to the driver. Normally, the driver allocates the DMA buffer and passes a virtual address to the app. Therefore, the DMA buffer processing for SG is completely different than for driver-allocated buffers, including the concept of a DMA buffer length.
For normal DMA buffers, I would specify a limit of 64KB just because of the problems with multiple calls to .hw_params() and .prepare(). I could support much larger DMA buffers, but not with the way ALSA calls the driver.
For SG, I haven't looked at the API, but I assume that the ALSA gives a list of physical addresses to the driver only *once*. In this case, my DMA buffer limitations are much larger, since I just give the list of addresses to my hardware and it does the rest. So I would hope that the application *doesn't* use the DMA buffer size limit in my snd_pcm_hardware structure.