[alsa-devel] Maximum buffer size on HDA

[Takashi Iwai]

At Mon, 16 Jun 2008 14:29:03 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Mon, 16 Jun 2008, Takashi Iwai wrote:
> 
> > At Mon, 16 Jun 2008 12:53:11 +0200 (CEST),
> > Jaroslav Kysela wrote:
> > > 
> > > On Mon, 16 Jun 2008, Takashi Iwai wrote:
> > > 
> > > > At Fri, 13 Jun 2008 21:13:03 +0200,
> > > > Lennart Poettering wrote:
> > > > > 
> > > > > Heya,
> > > > > 
> > > > > the HDA driver allows a playback buffer size of something like 64K
> > > > > onyl. Is this a driver limitation or a limitation of the hardware?
> > > > > Skimming through the docs I cannot see anything like this, and I got
> > > > > the idea that the audio buffer is maintained in system memory, not
> > > > > sound card memory, so why this limit?
> > > > 
> > > > This comes from the buffer pre-allocator.
> > > > Run the below:
> > > > 
> > > > 	# echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc
> > > > 
> > > > then you can use now 1MB buffer.  snd-hda-intel has max
> > > > pre-allocation buffer size 1MB, and this is the hard-coded limit.
> > > > 
> > > > It's rather a silly constraint, and I think it'd be better cut off.
> > > > OTOH, this makes the system safer (e.g. avoiding page allocations for
> > > > too large buffers), and there is a proper workaround, too.
> > > > So, I'm open about this change, so far.
> > > 
> > > Which workaround you're talking about?
> > 
> > Reset a proc file manually like the above.  Without this, you cannot
> > allocate the buffer over the pre-allocated size.
> 
> I'm not quite sure what you like to change. Make 1MB limit smaller? Or 
> change the default preallocated size? Or remove preallocation? I think 
> that it might make sense to increase the default preallocation value to 
> 128KB or 192KB.

We have some options:

A. Remove the sucking hw_constraint for the pre-allocated size
B. Remove/improve the whole pre-allocation mechanism
C. Increase the default pre-allocation size of snd-hda-intel
D. Ignore complains

I'm for, but still open about A.  B would be a good option if we can
(have time and resource).  C would be ad hoc but surely work for this
particular case.  D is the current status.


Takashi