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